Re: Why MarkBufferDirtyHint doesn't increment shared_blks_dirtied

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why MarkBufferDirtyHint doesn't increment shared_blks_dirtied
Date: 2014-03-26 05:07:08
Message-ID: CAA4eK1KQQSpNmfxg8Cg3-JZD23Q4Ee3iCsuLZGekH=DnaGPjRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 25, 2014 at 9:32 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

Attachment Content-Type Size
increment_dirty_buffer_count-v1.patch application/octet-stream 438 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-03-26 06:02:41 Re: issue log message to suggest VACUUM FULL if a table is nearly empty
Previous Message Robert Haas 2014-03-26 04:59:51 Re: Still something fishy in the fastpath lock stuff