Обсуждение: Why MarkBufferDirtyHint doesn't increment shared_blks_dirtied
MarkBufferDirty() always increment BufferUsage counter (shared_blks_dirtied) for dirty blocks whenever it dirties any block, whereas same is not true for MarkBufferDirtyHint(). Is there any particular reason for not incrementing shared_blks_dirtied in MarkBufferDirtyHint()? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On Tue, Mar 25, 2014 at 9:32 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> MarkBufferDirty() always increment BufferUsage counter
> (shared_blks_dirtied) for dirty blocks whenever it dirties any
> block, whereas same is not true for MarkBufferDirtyHint().
> Is there any particular reason for not incrementing
> shared_blks_dirtied in MarkBufferDirtyHint()?
The issue can be reproduced with below test:
postgresql.conf - autovacuum = off
create table t1(c1 int, c2 char(500)) with (fillfactor=10);
insert into t1 values(generate_series(1,10000),'aaa');
exit session (\q)
Stop and start the server
connect a new session
select count(*) from t1; -- here it has to mark each block dirty for
-- setting hint bit
postgres=# select query, shared_blks_dirtied from pg_stat_statements;
query | shared_blks_dirtied
------------------------------------+---------------------
select count(*) from t1; | 0
Above query should show shared_blks_dirtied = 10000.
Attached patch fixes this problem and result with patch is as below:
After following steps above again, it will show correct results.
postgres=# select query, shared_blks_dirtied from pg_stat_statements;
query | shared_blks_dirtied
------------------------------------+---------------------
select count(*) from t1; | 10000
As expected shared_blks_dirtied is 10000
I understand that issue is quite trivial, but fixing it will give correct
stats.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Вложения
On Mon, Mar 24, 2014 at 9:02 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > MarkBufferDirty() always increment BufferUsage counter > (shared_blks_dirtied) for dirty blocks whenever it dirties any > block, whereas same is not true for MarkBufferDirtyHint(). > Is there any particular reason for not incrementing > shared_blks_dirtied in MarkBufferDirtyHint()? Hmm, I think that's a bug, dating back to this commit: commit 2254367435fcc4a31cc3b6d8324e33c5c30f265a Author: Robert Haas <rhaas@postgresql.org> Date: Wed Feb 22 20:33:05 2012 -0500 Make EXPLAIN (BUFFERS) track blocks dirtied, as well as those written. Also expose the new counters through pg_stat_statements. Patch by me. Review by Fujii Masao and Greg Smith. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Mar 27, 2014 at 1:39 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Mar 24, 2014 at 9:02 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> MarkBufferDirty() always increment BufferUsage counter >> (shared_blks_dirtied) for dirty blocks whenever it dirties any >> block, whereas same is not true for MarkBufferDirtyHint(). >> Is there any particular reason for not incrementing >> shared_blks_dirtied in MarkBufferDirtyHint()? > > Hmm, I think that's a bug, dating back to this commit: > > commit 2254367435fcc4a31cc3b6d8324e33c5c30f265a Right. Do you think the fix attached in my previous mail is appropriate? http://www.postgresql.org/message-id/CAA4eK1KQQSpNmfxg8Cg3-JZD23Q4Ee3iCsuLZGekH=DnaGPjRA@mail.gmail.com With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On Wed, Mar 26, 2014 at 11:23 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Thu, Mar 27, 2014 at 1:39 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Mon, Mar 24, 2014 at 9:02 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >>> MarkBufferDirty() always increment BufferUsage counter >>> (shared_blks_dirtied) for dirty blocks whenever it dirties any >>> block, whereas same is not true for MarkBufferDirtyHint(). >>> Is there any particular reason for not incrementing >>> shared_blks_dirtied in MarkBufferDirtyHint()? >> >> Hmm, I think that's a bug, dating back to this commit: >> >> commit 2254367435fcc4a31cc3b6d8324e33c5c30f265a > > Right. > Do you think the fix attached in my previous mail is appropriate? > http://www.postgresql.org/message-id/CAA4eK1KQQSpNmfxg8Cg3-JZD23Q4Ee3iCsuLZGekH=DnaGPjRA@mail.gmail.com Looks right to me. Committed and back-patched to 9.2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company