Can we go anywhere with this?
> Bruce Momjian wrote:
> > Interesting. Nothing is jumping out at me. Looks like we could try to
> > clean up heapgettup() to see if there is anything in there that can be
> > speeded up.
> > None of the calls looks like it should be inlined. Do you see any that
> > look good for inlining?
> ExecScan() seems to be the only func which calls SeqNext(), which in
> turn accounts for 60% of the calls to heap_getnext(), which does 80% of
> the calls to heapgettup().
> - Put SeqNext() into ExecScan() to lower function call overhead? [minimal optim.]
> - In heapgettup(), 50% is the func itself and 50% is called funcs.
> Top four CPU consumers:
> 0.04 0.14 9924/9924 RelationGetBufferWithBuffer 
> 0.03 0.15 5642/5702 ReleaseAndReadBuffer 
> 0.10 0.00 26276/42896 nocachegetattr 
> 0.01 0.08 7111/9607 HeapTupleSatisfiesVisibility 
> RelationGetBufferWithBuffer() seems to be called from here only. If so, inline.
> - Looking at RelationGetBufferWithBuffer():
> 0.00 0.10 4603/32354 ReadBuffer 
> ReadBuffer() is the biggest cpu consumer called by RelationGetBufferWithBuffer(). (55%)
> -> *** 97% of ReadBuffer() CPU time is in calling ReadBufferWithBufferLock()
> -> 85% of ReadBufferWithBufferLock() CPU time is in calling BufferAlloc().
> -> ReadBufferWithBufferLock() is the only func calling BufferAlloc().
> -> Conclusion: INLINE BufferAlloc().
> - Looking at BufferAlloc():
> 0.04 0.25 37974/37974 BufTableLookup 
> 0.10 0.00 32340/151781 SpinAcquire 
> 0.10 0.00 37470/40585 PinBuffer 
> 0.08 0.00 38478/43799 RelationGetLRelId 
> 0.04 0.00 37974/151781 SpinRelease 
> -> 40% of BufferAlloc() CPU time is in calling BufTableLookup().
> -> BufferAlloc() is the only func calling BufTableLookup().
> -> Conclusion: INLINE BufTableLookup().
> - Looking at BufTableLookup():
> 86% of CPU time is in calling hash_search(). The rest is own time.
> - Looking at hash_search():
> 0.13 0.41 179189/179189 call_hash 
> 0.00 0.00 6/6 bucket_alloc 
> -> Conclusion: INLINE call_hash() [and bucket_alloc()] into hash_search().
> - Looking at call_hash():
> 0.37 0.00 171345/171345 tag_hash 
> 0.04 0.00 7844/7844 string_hash 
> -> Conclusion: INLINE tag_hash() [and string_hash()] into call_hash().
> -> Perhaps disk_hash() could be used in some way? It is currently #ifdef'd away.
> -> Could we use a lookup table instead of doing hash calculations? Would not that
> -> be much faster?
> It looks to me as if there are too many levels of function calls.
> Perhaps all functions which are called by only one other func should be inlined?
> This would speed up heapgettup() by 10% ???
> Other functions would speed up too.
> /* m */
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 1998-03-16 04:59:32|
|Subject: Re: [HACKERS] Some cleanups/enhancements|
|Previous:||From: Bruce Momjian||Date: 1998-03-16 04:40:48|
|Subject: Re: [HACKERS] VACUUM ANALYZE Problem|