From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core |
Date: | 2013-11-20 23:37:36 |
Message-ID: | CAM3SWZT582X_h=Vjdk23qhaVFGAMK5KLErwduHYCidiHVUr7sg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
With a pg_stat_statements.max of 1,000, on my system with the patch
applied the additional amount of shared memory required is only
192KiB. That compares with about 1.17MiB for the same setting in
master's version of pg_stat_statements. Surely with this huge
reduction, we should revisit that default - I think that a default
setting of 5,000 for pg_stat_statements.max makes more sense.
entry_dealloc() requires an exclusive lock, locking all queries out of
simply recording their costs. With a lot of cache pressure this could
be really expensive. In my opinion that risk alone justifies the
change.
Without adding another GUC, we might even go so far as to have a
mechanism like checkpoint_warning warn that entry_dealloc() calls
occur too frequently...
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-11-20 23:41:41 | Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1 |
Previous Message | Andres Freund | 2013-11-20 23:25:57 | Re: Storage formats for JSON WAS: additional json functionality |