Re: Number of Columns in a Table & SQL Performance ?
From: Greg Rahn <greg_at_structureddata.org>
Date: Tue, 10 Mar 2009 09:44:03 -0700
Message-ID: <a9c093440903100944i716d262bic18055ace56b4dc5_at_mail.gmail.com>
There is less "overhead" in accessing columns at the top/left of the table than further down. This is because once the row is found in the block, the row piece has to be walked to project the required columns. If those columns are at the top/left they are at the beginning of the row piece it takes less CPU/function calls to get to those versus the ones that are at the bottom/right or end of the row piece.
Date: Tue, 10 Mar 2009 09:44:03 -0700
Message-ID: <a9c093440903100944i716d262bic18055ace56b4dc5_at_mail.gmail.com>
There is less "overhead" in accessing columns at the top/left of the table than further down. This is because once the row is found in the block, the row piece has to be walked to project the required columns. If those columns are at the top/left they are at the beginning of the row piece it takes less CPU/function calls to get to those versus the ones that are at the bottom/right or end of the row piece.
On Mon, Mar 9, 2009 at 10:02 PM, John Kanagaraj
<john.kanagaraj_at_gmail.com> wrote:
> HOWEVER: If there are 400 columns, I would bet that most rows will not
> fit in one block and hence you will see a lot more 'db file sequential
> read' than normally required. As well, I remember that Steve Adams (or
> someone long ago) mentioning that there is an additional cost for
> accessing a column "further down the list" - sorry don't have that
> link.
-- Regards, Greg Rahn http://structureddata.org -- http://www.freelists.org/webpage/oracle-lReceived on Tue Mar 10 2009 - 11:44:03 CDT