Re: Planning counters in pg_stat_statements (using pgss_store)

2019-09-06 Thread Tomas Vondra
On Fri, Sep 06, 2019 at 04:19:16PM +0200, Tomas Vondra wrote: FWIW I've done some benchmarking on this too, with a single pgbench client running select-only test on a tiny database, in different modes (simple, extended, prepared). I've done that on two systems with different CPUs (spreadsheet

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-09-04 Thread Sergei Kornilov
Hello I think the most important question for this topic is performance penalty. It was a long story, first test on my desktop was too volatile. I setup separate PC with DB only and test few cases. PC spec: 2-core Intel Core 2 Duo E6550, 4GB ram, mechanical HDD All tests on top

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-07-01 Thread Julien Rouhaud
On Tue, Apr 2, 2019 at 9:22 AM legrand legrand wrote: > > >> case avg_tps pct_diff > >> 089 278 -- > >> 188 745 0,6% > >> 288 282 1,1% > >> 386 660 2,9% > >> > >> This means that even in this extrem test case, the worst degradation is > >> less > >>

RE: Planning counters in pg_stat_statements (using pgss_store)

2019-04-02 Thread legrand legrand
Hi, >> >> case avg_tps pct_diff >> 089 278 -- >> 188 745 0,6% >> 288 282 1,1% >> 386 660 2,9% >> >> This means that even in this extrem test case, the worst degradation is less >> than 3% >> (this overhead can be removed using

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-04-01 Thread Julien Rouhaud
On Mon, Apr 1, 2019 at 10:35 PM legrand legrand wrote: > > I have played with this patch, it works fine. Thanks for testing! > rem the last position of the "new" total_time column is confusing > +CREATE VIEW pg_stat_statements AS > + SELECT *, total_plan_time + total_exec_time AS total_time >

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-04-01 Thread legrand legrand
Hi, I have played with this patch, it works fine. rem the last position of the "new" total_time column is confusing +CREATE VIEW pg_stat_statements AS + SELECT *, total_plan_time + total_exec_time AS total_time +FROM pg_stat_statements(true); I wanted to perform some benchmark between

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-28 Thread Julien Rouhaud
On Thu, Mar 28, 2019 at 9:48 AM Julien Rouhaud wrote: > > On Thu, Mar 28, 2019 at 8:45 AM Sergei Kornilov wrote: > > > > >> Ok, but keep in mind that this is the last commitfest for pg12, and > > >> there are only 4 days left. Will you have time to take care of it, or > > >> do you need help

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-28 Thread Julien Rouhaud
On Thu, Mar 28, 2019 at 8:45 AM Sergei Kornilov wrote: > > >> Ok, but keep in mind that this is the last commitfest for pg12, and > >> there are only 4 days left. Will you have time to take care of it, or > >> do you need help on it? > > > > Oups, sorry, I won't have time nor knowledge to

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-28 Thread Sergei Kornilov
Hi >>  Ok, but keep in mind that this is the last commitfest for pg12, and >>  there are only 4 days left. Will you have time to take care of it, or >>  do you need help on it? > > Oups, sorry, I won't have time nor knowledge to finish in time ;o( > Any help is welcome ! No need to rush, this

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-27 Thread Julien Rouhaud
On Wed, Mar 27, 2019 at 9:36 PM legrand legrand wrote: > > >> - trailing whitespaces and comments wider than 80 characters > >> not fixed > > > why? In case it's not clear, I'm talking about the .c file, not the > > regression tests. > > I work on a poor msys install on windows 7,

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-27 Thread legrand legrand
>> - trailing whitespaces and comments wider than 80 characters >> not fixed > why? In case it's not clear, I'm talking about the .c file, not the > regression tests. I work on a poor msys install on windows 7, where perl is broken ;o( So no pgindent available. Will fix that

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-27 Thread Julien Rouhaud
On Wed, Mar 27, 2019 at 12:21 AM legrand legrand wrote: > > here is a new version: > > - "track_planning" GUC added > to permit to keep previous behavior unchanged good > - trailing whitespaces and comments wider than 80 characters > not fixed why? In case it's not

RE: Planning counters in pg_stat_statements (using pgss_store)

2019-03-26 Thread legrand legrand
here is a new version: - "track_planning" GUC added to permit to keep previous behavior unchanged - columns names have been changed / added: total_plan_time, total_exec_time, total_time - trailing whitespaces and comments wider than 80 characters not fixed

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-25 Thread legrand legrand
As there are now 3 locking times on pgss hash struct, one day or an other, somebody will ask for a GUC to disable this feature (to be able to run pgss unchanged with only one lock as today). With this GUC, pgss_store should be able to store the query text and accumulated execution duration in

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-24 Thread Julien Rouhaud
On Sat, Mar 23, 2019 at 11:08 PM legrand legrand wrote: > > > This patch has multiple trailing whitespace, indent and coding style > > issues. You should consider running pg_indent before submitting a > > patch. I attach the diff after running pgindent if you want more > > details about the

RE: Planning counters in pg_stat_statements (using pgss_store)

2019-03-23 Thread legrand legrand
> This patch has multiple trailing whitespace, indent and coding style > issues. You should consider running pg_indent before submitting a > patch. I attach the diff after running pgindent if you want more > details about the various issues. fixed > - * Track statement execution times

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-23 Thread Julien Rouhaud
On Fri, Mar 22, 2019 at 11:46 PM legrand legrand wrote: > > Here is a rebased and corrected version . This patch has multiple trailing whitespace, indent and coding style issues. You should consider running pg_indent before submitting a patch. I attach the diff after running pgindent if you

RE: Planning counters in pg_stat_statements (using pgss_store)

2019-03-22 Thread legrand legrand
Hi, Here is a rebased and corrected version . Columns naming has not been modified, I would propose to change it to: - plans: ok - planning_time --> plan_time - calls: ok - total_time --> exec_time - {min,max,mean,stddev}_time: ok - new total_time (being the sum of plan_time and exec_time)

Re: Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-20 Thread David Steele
Hi PAscal, On 2/15/19 11:32 AM, Sergei Kornilov wrote: Hi  +#define PG_STAT_STATEMENTS_COLS_V1_4 25 I thought it was needed when adding new columns, isn't it ? Yes, this is needed. I mean it should be PG_STAT_STATEMENTS_COLS_V1_8: because such change was made for 1.8 pg_stat_statements

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-02-14 Thread Sergei Kornilov
Hi >>  +#define PG_STAT_STATEMENTS_COLS_V1_4 25 > > I thought it was needed when adding new columns, isn't it ? Yes, this is needed. I mean it should be PG_STAT_STATEMENTS_COLS_V1_8: because such change was made for 1.8 pg_stat_statements version. Same thing for other version-specific places.

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-02-14 Thread legrand legrand
Thank you Sergei for your comments, > Did you register patch in CF app? I did not found entry. created today: https://commitfest.postgresql.org/22/1999/ > Currently we have pg_stat_statements 1.7 version and this patch does not > apply... will rebase and create a 1.8 version > -

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-02-12 Thread Sergei Kornilov
Hi > I think it is related to https://commitfest.postgresql.org/16/1373/ > but I don't know how to link it with. You can just add new entry in open commitfest and then attach previous thread. This is usual way for pick up old patches. For example, as i did here:

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-02-12 Thread legrand legrand
Hi Sergei, Thank you for this review ! >Did you register patch in CF app? I did not found entry. I think it is related to https://commitfest.postgresql.org/16/1373/ but I don't know how to link it with. Yes, there are many things to improve, but before to go deeper, I would like to know if

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-02-12 Thread Sergei Kornilov
Hello Thank you for picking this up! Did you register patch in CF app? I did not found entry. Currently we have pg_stat_statements 1.7 version and this patch does not apply... My fast and small view: > - errmsg("could not read file \"%s\": %m", > +

<    1   2