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 |
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 |