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