Re: Add min and max execute statement time in pg_stat_statement - Mailing list pgsql-hackers

From KONDO Mitsumasa
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id 52E07047.9030307@lab.ntt.co.jp
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Add min and max execute statement time in pg_stat_statement  (Peter Geoghegan <pg@heroku.com>)
Re: Add min and max execute statement time in pg_stat_statement  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
(2014/01/22 22:26), Robert Haas wrote:
> On Wed, Jan 22, 2014 at 3:32 AM, KONDO Mitsumasa
> <kondo.mitsumasa@lab.ntt.co.jp> wrote:
>>> OK, Kondo, please demonstrate benchmarks that show we have <1% impact
>>> from this change. Otherwise we may need a config parameter to allow
>>> the calculation.
>>
>> OK, testing DBT-2 now. However, error range of benchmark might be 1% higher.
>> So I show you detail HTML results.
>
> To see any impact from spinlock contention, I think you're pretty much
> going to need a machine with >32 cores, I think, and lots of
> concurrency.  pgbench -S is probably a better test than DBT-2, because
> it leaves out all the writing, so percentage-wise more time will be
> spent doing things like updating the pgss hash table.
Oh, thanks to inform me. I think essential problem of my patch has bottle neck in 
sqrt() function and other division caluculation. I will replcace sqrt() function 
in math.h to more faster algorithm. And moving unneccessary part of caluculation 
in LWlocks or other locks. It might take time to improvement, so please wait for 
a while.

Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Next
From: Peter Geoghegan
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement