Re: [HACKERS] Profile of current backend - Mailing list pgsql-hackers

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 [148]
    0.03    0.15    5642/5702        ReleaseAndReadBuffer [145]
    0.10    0.00   26276/42896       nocachegetattr [158]
    0.01    0.08    7111/9607        HeapTupleSatisfiesVisibility [185]

  RelationGetBufferWithBuffer() seems to be called from here only. If so, inline.

- Looking at RelationGetBufferWithBuffer():
    0.00    0.10    4603/32354       ReadBuffer [55]
  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 [114]
    0.10    0.00   32340/151781      SpinAcquire [81]
    0.10    0.00   37470/40585       PinBuffer [209]
    0.08    0.00   38478/43799       RelationGetLRelId [234]
    0.04    0.00   37974/151781      SpinRelease [175]

  -> 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 [69]
    0.00    0.00       6/6           bucket_alloc [1084]
  -> Conclusion: INLINE call_hash() [and bucket_alloc()] into hash_search().

- Looking at call_hash():
    0.37    0.00  171345/171345      tag_hash [94]
    0.04    0.00    7844/7844        string_hash [348]
  -> 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?


Guesstimate:
  This would speed up heapgettup() by 10% ???
  Other functions would speed up too.


/* m */