| 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: | Whole Thread | Raw Message | 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 |