Re: Add min and max execute statement time in pg_stat_statement

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(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-27 12:45:18
Message-ID: 52E654DE.6060609@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 01/27/2014 07:09 AM, KONDO Mitsumasa wrote:
> (2014/01/23 23:18), Andrew Dunstan wrote:
>> What is more, if the square root calculation is affecting your
>> benchmarks, I
>> suspect you are benchmarking the wrong thing.
> I run another test that has two pgbench-clients in same time, one is
> select-only-query and another is executing 'SELECT * 
> pg_stat_statement' query in every one second. I used v6 patch in this
> test.
>

The issue of concern is not the performance of pg_stat_statements, AUIU.
The issue is whether this patch affects performance generally, i.e. is
there a significant cost in collecting these extra stats. To test this
you would compare two general pgbench runs, one with the patch applied
and one without. I personally don't give a tinker's cuss about whether
the patch slows down pg_stat_statements a bit.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru Hanada 2014-01-27 12:49:34 Re: [Review] inherit support for foreign tables
Previous Message KONDO Mitsumasa 2014-01-27 12:16:59 Re: Add min and max execute statement time in pg_stat_statement