From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Q about heap_getattr |
Date: | 1999-01-24 20:05:05 |
Message-ID: | 8044.917208305@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Tom Lane wrote:
>>>> I've been doing some more backend profiling, and observe that in a large
>>>> SELECT from a table with lots of columns, nocachegetattr (the guts of
>>>> heap_getattr) is at the top of the list, accounting for about 15% of
>>>> runtime.
>>>>
>>>> The percentage would be lower in a table with fewer columns or no null
>>>> columns, but it still seems worth working on. (Besides, this case right
>>>> here is a real-world case for me.)
> nocachegetattr() computes all offsets, even offsets after the column you
> are requesting, to prevent future calls. You must have nulls or
> varlena's that is causing nocachegetattr to be called so many times.
> Is this true?
Right, this table has 38 columns, many of which can be NULL and several
of which are variable-size. So it's probably the worst-case scenario as
far as the cost of nocachegetattr is concerned. It looked to me like
the pre-computation aspect of nocachegetattr only works for tables where
all the tuples have the same physical layout, ie, no varlenas or nulls;
is that right?
> heap_getattr() certainly is called many times, and needs any
> optimization we can give it. I have done as much as I could. Perhaps
> there are more opportunities I missed.
I thought I had spotted a couple of possibilities for small improvements
of the code inside nocachegetattr, but it was awfully late by then so
I didn't try changing anything. I'll take another look.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 1999-01-24 20:36:31 | Foreign key parsing and inherited classes |
Previous Message | Tom Lane | 1999-01-24 19:54:52 | Re: [HACKERS] Postgres Speed or lack thereof |