| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Marc Mamin <M(dot)Mamin(at)intershop(dot)de>, KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>, Stephen Frost <sfrost(at)snowman(dot)net>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add min and max execute statement time in pg_stat_statement |
| Date: | 2013-10-23 23:24:41 |
| Message-ID: | CAM3SWZQ8yp4Xaey__kgdXger6PXwGPD1FLpfv2qj9evqyvyq6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 23, 2013 at 4:14 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> The last bucket would be limited to 8ms < x <= 16 ms. If you find something
>> 16ms, then you have to rescale *before* you increment any of the buckets.
> Once you do, there is now room to hold it.
How is that laid out in shared memory? If the answer is an array of 32
int64s, one per bucket, -1 from me to this proposal. A huge advantage
of pg_stat_statements today is that the overhead is actually fairly
modest. I really want to preserve that property.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2013-10-23 23:26:28 | Re: Add min and max execute statement time in pg_stat_statement |
| Previous Message | Jeff Janes | 2013-10-23 23:14:25 | Re: Add min and max execute statement time in pg_stat_statement |