Re: [HACKERS] Performance problem partially identified

Tom Lane wrote:
> 
> Poking around for the cause, I find that heapgettup() calls
> SetBufferCommitInfoNeedsSave() for every single tuple read from the
> table:
> 
>                 7.14   42.15 1000055/1000055     heap_getnext [9]
> [10]    18.8    7.14   42.15 1000055         heapgettup [10]
>                 1.53   30.10 1000020/1000020     HeapTupleSatisfiesSnapshot [11]
>                 1.68    3.27 1000055/1000055     RelationGetBufferWithBuffer [50]
>                 4.31    0.00 2066832/4129472     LockBuffer [45]
>                 0.25    0.56   33361/33698       ReleaseAndReadBuffer [76]
>                 0.44    0.00 1000000/1000000     SetBufferCommitInfoNeedsSave [92]
>                 0.01    0.00   33371/33371       nextpage [240]
>                 0.00    0.00      10/2033992     ReleaseBuffer [46]
>                 0.00    0.00      45/201         HeapTupleSatisfiesNow [647]
>                 0.00    0.00       5/9           nocachegetattr [730]
> 
> This could only be from the call to SetBufferCommitInfoNeedsSave in
> the HeapTupleSatisfies macro.  If I'm reading the code correctly,
> that means that HeapTupleSatisfiesSnapshot() always changes the
^^^^^^^^^^^^^^
> t_infomask field of the tuple.

Not always but only if HEAP_XMIN_COMMITTED/HEAP_XMAX_COMMITTED
are not setted. Run vacuum before update and SetBufferCommitInfoNeedSave
will not be called. This func is just to avoid pg_log lookup
without vacuum.

Vadim