Re: Add min and max execute statement time in pg_stat_statement

From: KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add min and max execute statement time in pg_stat_statement
Date: 2014-01-23 12:43:22
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

(2014/01/23 10:28), Peter Geoghegan wrote:
> On Wed, Jan 22, 2014 at 5:28 PM, KONDO Mitsumasa
> <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Oh, thanks to inform me. I think essential problem of my patch has bottle
>> neck in sqrt() function and other division caluculation.
> Well, that's a pretty easy theory to test. Just stop calling them (and
> do something similar to what we do for current counter fields instead)
> and see how much difference it makes.
What means "calling them"? I think that part of heavy you think is
pg_stat_statement view that is called by select query, not a part of LWLock
getting statistic by hook. Right?

I tested my patch in pgbench, but I cannot find bottleneck of my latest patch.
(Sorry, I haven't been test select query in pg_stat_statement view...) Here is a
test result.

* Result (Test result is represented by tps.)
method | try1 | try2 | try3
without pgss | 130938 | 131558 | 131796
with pgss | 125164 | 125146 | 125358
with patched pgss| 126091 | 126681 | 126433

* Test Setting
checkpoint_segments = 300
checkpoint_timeout = 15min
checkpoint_completion_target = 0.7

* pgbench script
pgbench -h mitsu-ko -i -s 100
psql -h mitsu-ko -c 'CHECKPOINT'
pgbench -h mitsu-ko -c64 -j32 -S -T 180
pgbench -h mitsu-ko -c64 -j32 -S -T 180
pgbench -h mitsu-ko -c64 -j32 -S -T 180

* Server SPEC:
CPU: Xeon E5-2670 1P/8C 2.6GHz #We don't have 32 core cpu...
Memory: 24GB
RAID: i420 2GB cache
Disk: 15K * 6 (RAID 1+0)

Attached is latest developping patch. It hasn't been test much yet, but sqrt
caluclation may be faster.

Mitsumasa KONDO
NTT Open Source Software Center

Attachment Content-Type Size
pg_stat_statements-exectime_v5.patch text/x-diff 11.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-01-23 12:56:49 Re: Hard limit on WAL space used (because PANIC sucks)
Previous Message Andres Freund 2014-01-23 12:05:03 Re: Changeset Extraction v7.0 (was logical changeset generation)