> 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.)
> >
> > What's drawing my eye is that printtup() is calling heap_getattr twice
> > for each attribute of each tuple --- once in the first scan that
> > prepares the null-fields bitmap, and then again to actually output the
> > field value. So, what I want to do is call heap_getattr only once per
> > attribute and save the returned value for use in the second loop.
> > That should halve the time spent in nocachegetattr and thus knock
> > 7 or so percent off the runtime of SELECT.
>
> Try to use heap_attisnull in first scan!
> This func just tests nulls bitmap array of tuple...
>
> Vadim
> P.S. Tom, I forgot to attach new allocation code in my prev letter,
> but now I want to reimplement them.
>
>
Good idea. Hadn't thought of that. To answer Tom's question, it
doesn't matter how many times you call heap_getattr(). You can cache
the values, as long as the tuple doesn't change.
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?
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.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
