From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Performance problem partially identified |
Date: | 1999-05-29 04:55:28 |
Message-ID: | 374F7340.DC1C16DC@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-05-29 04:58:23 | Re: [HACKERS] Performance problem partially identified |
Previous Message | Tatsuo Ishii | 1999-05-29 02:20:02 | Re: [HACKERS] Problems w/ LO |