Re: [HACKERS] Q about heap_getattr

> Bruce Momjian <maillist@candle.pha.pa.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.

Also, I see a few places where heap_getattr is called, just looking for
a null.  You can use mkid(see developers faq) to find them.  If you
don't modify them, I can.

--  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