Re: Why MarkBufferDirtyHint doesn't increment shared_blks_dirtied - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Why MarkBufferDirtyHint doesn't increment shared_blks_dirtied
Date
Msg-id CAA4eK1KQQSpNmfxg8Cg3-JZD23Q4Ee3iCsuLZGekH=DnaGPjRA@mail.gmail.com
Whole thread Raw
In response to Why MarkBufferDirtyHint doesn't increment shared_blks_dirtied  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Still something fishy in the fastpath lock stuff
Next
From: Robert Haas
Date:
Subject: Re: issue log message to suggest VACUUM FULL if a table is nearly empty