Re: Planning counters in pg_stat_statements (using pgss_store) - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: Planning counters in pg_stat_statements (using pgss_store)
Date
Msg-id 6112091549979517@myt5-a323eb993ef7.qloud-c.yandex.net
Whole thread Raw
In response to Planning counters in pg_stat_statements (using pgss_store)  (legrand legrand <legrand_legrand@hotmail.com>)
Responses Re: Planning counters in pg_stat_statements (using pgss_store)
Re: Planning counters in pg_stat_statements (using pgss_store)
List pgsql-hackers
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",
> +             errmsg("could not read pg_stat_statement file \"%s\": %m",

Not sure this is need for this patch. Usually refactoring and new features are different topics.

> +#define PG_STAT_STATEMENTS_COLS_V1_4    25

should not be actual version? I think version in names is relevant to extension version.

And this patch does not have documentation changes.

> "I agree with the sentiment on the old thread that
> {total,min,max,mean,stddev}_time now seem badly named, but adding
> execution makes them so long...  Thoughts?"
>
> What would you think about:
> - userid
> - dbid
> - queryid
> - query
> - plans
> - plan_time
> - {min,max,mean,stddev}_plan_time
> - calls
> - exec_time
> - {min,max,mean,stddev}_exec_time
> - total_time (being the sum of plan_time and exec_time)
> - rows
> - ...

We have some consensus about backward incompatible changes in this function? *plan_time + *exec_time naming is ok for
me

regards, Sergei


pgsql-hackers by date:

Previous
From: Oleksii Kliukin
Date:
Subject: Re: Connection slots reserved for replication
Next
From: Alvaro Herrera
Date:
Subject: Re: Too rigorous assert in reorderbuffer.c