Re: Planning counters in pg_stat_statements (using pgss_store)

On 2021/07/26 12:32, Julien Rouhaud wrote: On Sun, Jul 25, 2021 at 11:26:02PM -0400, Tom Lane wrote: Julien Rouhaud writes: I attach a patch that splits the test and add a comment explaining the boundaries for the new query. Checked with and without forced invalidations. Pushed with a

Re: Planning counters in pg_stat_statements (using pgss_store)

On Sun, Jul 25, 2021 at 11:26:02PM -0400, Tom Lane wrote: > Julien Rouhaud writes: > > I attach a patch that splits the test and add a comment explaining the > > boundaries for the new query. > > Checked with and without forced invalidations. > > Pushed with a little cosmetic fooling-about.

Re: Planning counters in pg_stat_statements (using pgss_store)

Julien Rouhaud writes: > I attach a patch that splits the test and add a comment explaining the > boundaries for the new query. > Checked with and without forced invalidations. Pushed with a little cosmetic fooling-about. regards, tom lane

Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Jul 26, 2021 at 01:08:08AM +0800, Julien Rouhaud wrote: > Le lun. 26 juil. 2021 à 00:59, Tom Lane a écrit : > > > Julien Rouhaud writes: > > > On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote: > > > > > > Would it be worth to split the query for the prepared statement row vs >

Re: Planning counters in pg_stat_statements (using pgss_store)

Andrew Dunstan writes: > On 7/25/21 12:03 PM, Tom Lane wrote: >> So AFAICS this test is inherently unstable and there is no code bug >> to be fixed. We could drop the "plans" column from this query, or >> print something approximate like "plans > 0 AND plans <= calls". >> Thoughts? > Is that

Re: Planning counters in pg_stat_statements (using pgss_store)

On 7/25/21 12:03 PM, Tom Lane wrote: > > So AFAICS this test is inherently unstable and there is no code bug > to be fixed. We could drop the "plans" column from this query, or > print something approximate like "plans > 0 AND plans <= calls". > Thoughts? > Is that likely to tell us anything

Re: Planning counters in pg_stat_statements (using pgss_store)

Le lun. 26 juil. 2021 à 00:59, Tom Lane a écrit : > Julien Rouhaud writes: > > On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote: > > > Would it be worth to split the query for the prepared statement row vs > the rest > > to keep the full "plans" coverage when possible? > > +1, the same

Re: Planning counters in pg_stat_statements (using pgss_store)

Julien Rouhaud writes: > On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote: >> So AFAICS this test is inherently unstable and there is no code bug >> to be fixed. We could drop the "plans" column from this query, or >> print something approximate like "plans > 0 AND plans <= calls". >>

Re: Planning counters in pg_stat_statements (using pgss_store)

On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote: > The cause of the failure of course is that cache clobbering includes > plan cache clobbering, so that the prepared statement's plan is > remade each time it's used, not only twice as the test expects. > However, remembering that cache

Re: Planning counters in pg_stat_statements (using pgss_store)

[ blast from the past department ] Fujii Masao writes: > Finally I pushed the patch! > Many thanks for all involved in this patch! It turns out that the regression test outputs from this patch are unstable under debug_discard_caches (nee CLOBBER_CACHE_ALWAYS). You can easily check this in HEAD

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, May 22, 2020 at 9:51 PM Fujii Masao wrote: > > > On 2020/05/22 15:10, Andy Fan wrote: > > > > > > On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud > wrote: > > > > Le jeu. 21 mai 2020 à 09:17, Michael Paquier > a écrit : > > > >

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, May 22, 2020 at 9:27 PM legrand legrand wrote: > > >> If we can store the plan for each statement, e.g., like pg_store_plans > >> extension [1] does, rather than such partial information, which would > >> be enough for your cases? > > > That'd definitely address way more use cases. Do

Re: Planning counters in pg_stat_statements (using pgss_store)

>> If we can store the plan for each statement, e.g., like pg_store_plans >> extension [1] does, rather than such partial information, which would >> be enough for your cases? > That'd definitely address way more use cases. Do you know if some > benchmark were done to see how much overhead such

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, May 22, 2020 at 3:51 PM Fujii Masao wrote: > > On 2020/05/22 15:10, Andy Fan wrote: > > > > > > On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud > > wrote: > > > > Le jeu. 21 mai 2020 à 09:17, Michael Paquier > > a écrit : > > > >

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/05/22 15:10, Andy Fan wrote: On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud mailto:rjuju...@gmail.com>> wrote: Le jeu. 21 mai 2020 à 09:17, Michael Paquier mailto:mich...@paquier.xyz>> a écrit : On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: >

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud wrote: > Le jeu. 21 mai 2020 à 09:17, Michael Paquier a > écrit : > >> On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: >> > On Tue, May 19, 2020 at 4:29 AM Andy Fan >> wrote: >> >> Thanks for the excellent extension. I want to add

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, May 21, 2020 at 3:17 PM Michael Paquier wrote: > On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: > > On Tue, May 19, 2020 at 4:29 AM Andy Fan > wrote: > >> Thanks for the excellent extension. I want to add 5 more fields to > satisfy the > >> following requirements. > >>

Re: Planning counters in pg_stat_statements (using pgss_store)

Le jeu. 21 mai 2020 à 09:17, Michael Paquier a écrit : > On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: > > On Tue, May 19, 2020 at 4:29 AM Andy Fan > wrote: > >> Thanks for the excellent extension. I want to add 5 more fields to > satisfy the > >> following requirements. > >>

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: > On Tue, May 19, 2020 at 4:29 AM Andy Fan wrote: >> Thanks for the excellent extension. I want to add 5 more fields to satisfy >> the >> following requirements. >> >> int subplan; /* No. of subplan in this query */ >> int

Re: Planning counters in pg_stat_statements (using pgss_store)

On Tue, May 19, 2020 at 4:29 AM Andy Fan wrote: > > Thanks for the excellent extension. I want to add 5 more fields to satisfy the > following requirements. > > int subplan; /* No. of subplan in this query */ > int subquery; /* No. of subquery */ > int joincnt; /* How many relations are

Re: Planning counters in pg_stat_statements (using pgss_store)

Thanks for the excellent extension. I want to add 5 more fields to satisfy the following requirements. int subplan; /* No. of subplan in this query */ int subquery; /* No. of subquery */ int joincnt; /* How many relations are joined */ bool hasagg; /* if we have agg function in this query

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/09 22:31, Julien Rouhaud wrote: On Thu, Apr 9, 2020 at 5:59 AM Fujii Masao wrote: On 2020/04/08 18:31, Julien Rouhaud wrote: On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: On 2020/04/03 16:26, Julien Rouhaud wrote: On Thu, Apr 02, 2020 at 01:04:28PM -0700,

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Apr 9, 2020 at 5:59 AM Fujii Masao wrote: > > > > On 2020/04/08 18:31, Julien Rouhaud wrote: > > On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: > >> > >> > >> On 2020/04/03 16:26, Julien Rouhaud wrote: > >>> On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote: >

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/08 21:32, legrand legrand wrote: Fujii Masao-4 wrote On 2020/04/03 16:26 [...] "Note that planning and execution statistics are updated only at their respective end phase, and only for successful operations. For example the execution counters of a long running query will only be

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/08 18:31, Julien Rouhaud wrote: On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: On 2020/04/03 16:26, Julien Rouhaud wrote: On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote: Fujii Masao-4 wrote On 2020/04/01 18:19, Fujii Masao wrote: Finally I

Re: Planning counters in pg_stat_statements (using pgss_store)

Fujii Masao-4 wrote > On 2020/04/03 16:26 > [...] >> >> "Note that planning and execution statistics are updated only at their >> respective end phase, and only for successful operations. >> For example the execution counters of a long running query >> will only be updated at the execution end,

Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: > > > On 2020/04/03 16:26, Julien Rouhaud wrote: > > On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote: > > > Fujii Masao-4 wrote > > > > On 2020/04/01 18:19, Fujii Masao wrote: > > > > > > > > Finally I pushed the

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/03 16:26, Julien Rouhaud wrote: On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote: Fujii Masao-4 wrote On 2020/04/01 18:19, Fujii Masao wrote: Finally I pushed the patch! Many thanks for all involved in this patch! As a remaining TODO item, I'm thinking that the

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote: > Fujii Masao-4 wrote > > On 2020/04/01 18:19, Fujii Masao wrote: > > > > Finally I pushed the patch! > > Many thanks for all involved in this patch! > > > > As a remaining TODO item, I'm thinking that the document would need to >

Re: Planning counters in pg_stat_statements (using pgss_store)

Fujii Masao-4 wrote > On 2020/04/01 18:19, Fujii Masao wrote: > > Finally I pushed the patch! > Many thanks for all involved in this patch! > > As a remaining TODO item, I'm thinking that the document would need to > be improved. For example, previously the query was not stored in pgss > when it

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/01 18:19, Fujii Masao wrote: On 2020/04/01 3:42, Julien Rouhaud wrote: On Wed, Apr 01, 2020 at 02:43:10AM +0900, Fujii Masao wrote: On 2020/03/31 16:33, Julien Rouhaud wrote: v12 attached! Thanks for updating the patch! The patch looks good to me. I applied minor and

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/01 3:42, Julien Rouhaud wrote: On Wed, Apr 01, 2020 at 02:43:10AM +0900, Fujii Masao wrote: On 2020/03/31 16:33, Julien Rouhaud wrote: v12 attached! Thanks for updating the patch! The patch looks good to me. I applied minor and cosmetic changes into the patch. Attached is

Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Apr 01, 2020 at 02:43:10AM +0900, Fujii Masao wrote: > > > On 2020/03/31 16:33, Julien Rouhaud wrote: > > > > v12 attached! > > Thanks for updating the patch! The patch looks good to me. > > I applied minor and cosmetic changes into the patch. Attached is > the updated version of the

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/31 16:33, Julien Rouhaud wrote: On Tue, Mar 31, 2020 at 04:10:47PM +0900, Fujii Masao wrote: On 2020/03/31 15:03, Julien Rouhaud wrote: On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote: On 2020/03/31 3:16, Julien Rouhaud wrote: On Mon, Mar 30, 2020 at 6:36 PM Fujii

Re: Planning counters in pg_stat_statements (using pgss_store)

On Tue, Mar 31, 2020 at 04:10:47PM +0900, Fujii Masao wrote: > > > On 2020/03/31 15:03, Julien Rouhaud wrote: > > On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote: > > > > > > On 2020/03/31 3:16, Julien Rouhaud wrote: > > > > On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao > > > >

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/31 15:03, Julien Rouhaud wrote: On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote: On 2020/03/31 3:16, Julien Rouhaud wrote: On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao wrote: While testing the patched pgss, I found that the patched version may track the statements

Re: Planning counters in pg_stat_statements (using pgss_store)

On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote: > > On 2020/03/31 3:16, Julien Rouhaud wrote: > > On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao > > wrote: > > > > > > While testing the patched pgss, I found that the patched version > > > may track the statements that the original

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/31 3:16, Julien Rouhaud wrote: On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao wrote: On 2020/03/30 17:03, Julien Rouhaud wrote: On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote: On 2020/03/29 15:15, Julien Rouhaud wrote: On Fri, Mar 27, 2020 at 03:42:50PM +0100,

Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao wrote: > > On 2020/03/30 17:03, Julien Rouhaud wrote: > > On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote: > >> > >> > >> On 2020/03/29 15:15, Julien Rouhaud wrote: > >>> On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote: >

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/30 17:03, Julien Rouhaud wrote: On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote: On 2020/03/29 15:15, Julien Rouhaud wrote: On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote: On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao wrote: So what I'd like to

Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote: > > > On 2020/03/29 15:15, Julien Rouhaud wrote: > > On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote: > > > On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao > > > wrote: > > > > > > > > > > > So what I'd like to say is

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/29 15:15, Julien Rouhaud wrote: On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote: On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao wrote: So what I'd like to say is that the information that users are interested in would vary on each situation and case. At least for

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote: > On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao > wrote: > > > > > So what I'd like to say is that the information that users are interested > > in would vary on each situation and case. At least for me it seems > > enough for pgss

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao wrote: > > On 2020/03/27 19:00, Julien Rouhaud wrote: > > On Thu, Mar 26, 2020 at 02:22:47PM +0100, Julien Rouhaud wrote: > >> On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote: > >>> > >>> Here are other comments. > >>> > >>> - if

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Mar 27, 2020 at 12:02 PM Fujii Masao wrote: > > On 2020/03/27 19:00, Julien Rouhaud wrote: > > On Thu, Mar 26, 2020 at 02:22:47PM +0100, Julien Rouhaud wrote: > >> On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote: > >>> > >>> Here are other comments. > >>> > >>> - if

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/27 19:00, Julien Rouhaud wrote: On Thu, Mar 26, 2020 at 02:22:47PM +0100, Julien Rouhaud wrote: On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote: Here are other comments. - if (jstate) + if (kind == PGSS_JUMBLE) Why is PGSS_JUMBLE

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/27 19:00, Julien Rouhaud wrote: On Thu, Mar 26, 2020 at 02:22:47PM +0100, Julien Rouhaud wrote: On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote: Here are other comments. - if (jstate) + if (kind == PGSS_JUMBLE) Why is PGSS_JUMBLE

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 26, 2020 at 02:22:47PM +0100, Julien Rouhaud wrote: > On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote: > > > > Here are other comments. > > > > - if (jstate) > > + if (kind == PGSS_JUMBLE) > > > > Why is PGSS_JUMBLE necessary? ISTM that we can still

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote: > > On 2020/03/25 22:45, Julien Rouhaud wrote: > > On Wed, Mar 25, 2020 at 10:09:37PM +0900, Fujii Masao wrote: > > > + /* > > > + * We can't process the query if no query_text is provided, as > > > pgss_store > > > + * needs it. We

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/25 22:45, Julien Rouhaud wrote: On Wed, Mar 25, 2020 at 10:09:37PM +0900, Fujii Masao wrote: On 2020/03/21 4:30, Julien Rouhaud wrote: On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote: Hello Yet another is missed in docs: total_time Oh good catch! I rechecked

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/26 2:17, Sergei Kornilov wrote: Hello WAL usage patch [1] increments this version to 1_4 instead of 1_8. I *guess* that's because previously this version was maintained independently from pg_stat_statements' version. For example, pg_stat_statements 1.4 seems to have used

Re: Planning counters in pg_stat_statements (using pgss_store)

Hello > WAL usage patch [1] increments this version to 1_4 instead of 1_8. > I *guess* that's because previously this version was maintained > independently from pg_stat_statements' version. For example, > pg_stat_statements 1.4 seems to have used PGSS_V1_3. As far as I remember, this was my

Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Mar 25, 2020 at 10:09:37PM +0900, Fujii Masao wrote: > > On 2020/03/21 4:30, Julien Rouhaud wrote: > > On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote: > > > Hello > > > > > > Yet another is missed in docs: total_time > > > > Oh good catch! I rechecked many time the

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/21 4:30, Julien Rouhaud wrote: On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote: Hello Yet another is missed in docs: total_time Oh good catch! I rechecked many time the field, and totally missed that the documentation is referring to the view, which has an

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote: > Hello > > Yet another is missed in docs: total_time Oh good catch! I rechecked many time the field, and totally missed that the documentation is referring to the view, which has an additional column, and not the function.

Re: Planning counters in pg_stat_statements (using pgss_store)

Hello I was inactive for a while... Sorry. >>  BTW, I recheck the patchset. >>  I think codes are ready for committer but should we modify the >> documentation? >>  {min,max,mean,stddev}_time is now obsoleted so it is better to modify it to >>  {min,max,mean,stddev}_exec_time and add

RE: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Mar 16, 2020 at 9:49 PM, Julien Rouhaud wrote: > On Mon, Mar 16, 2020 at 01:34:11AM +, imai.yoshik...@fujitsu.com > wrote: > > On Sat, Mar 14, 2020 at 5:28 PM, Julien Rouhaud wrote: > > > I don't think that's a correct assumption. I obviously didn't read > > > all of citus extension,

Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Mar 16, 2020 at 01:34:11AM +, imai.yoshik...@fujitsu.com wrote: > On Sat, Mar 14, 2020 at 5:28 PM, Julien Rouhaud wrote: > > I don't think that's a correct assumption. I obviously didn't read all of > > citus extension, but it looks like what's happening is that they get > > generate

Re: Planning counters in pg_stat_statements (using pgss_store)

> I'm instead attaching a v7 which removes the assert in pg_plan_query, and > modify pgss_planner_hook to also ignore queries without a query text, as > this > seems the best option. Ok, it was the second solution, go on ! -- Sent from:

RE: Planning counters in pg_stat_statements (using pgss_store)

On Sat, Mar 14, 2020 at 5:28 PM, Julien Rouhaud wrote: > On Sat, Mar 14, 2020 at 03:04:00AM -0700, legrand legrand wrote: > > imai.yoshik...@fujitsu.com wrote > > > On Thu, Mar 12, 2020 at 6:37 PM, Julien Rouhaud wrote: > > >> That's very interesting feedback, thanks! I'm not a fan of giving a

Re: Planning counters in pg_stat_statements (using pgss_store)

On Sat, Mar 14, 2020 at 03:04:00AM -0700, legrand legrand wrote: > imai.yoshik...@fujitsu.com wrote > > On Thu, Mar 12, 2020 at 6:37 PM, Julien Rouhaud wrote: > >> That's very interesting feedback, thanks! I'm not a fan of giving a way > >> for > >> queries to say that they want to be ignored by

RE: Planning counters in pg_stat_statements (using pgss_store)

> I don't know it is useful but there are also codes that avoid an error when > sourceText is NULL. > executor_errposition(EState *estate, int location) > { > ... >/* Can't do anything if source text is not available */ >if (estate == NULL || estate->es_sourceText == NULL) > } or

RE: Planning counters in pg_stat_statements (using pgss_store)

imai.yoshik...@fujitsu.com wrote > On Thu, Mar 12, 2020 at 6:37 PM, Julien Rouhaud wrote: >> On Thu, Mar 12, 2020 at 1:11 PM Marco Slot > marco.slot@ > wrote: >> > On Thu, Mar 12, 2020 at 11:31 AM Julien Rouhaud > rjuju123@ > >> wrote: >> > > There's at least the current version of IVM

RE: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 12, 2020 at 6:37 PM, Julien Rouhaud wrote: > On Thu, Mar 12, 2020 at 1:11 PM Marco Slot wrote: > > On Thu, Mar 12, 2020 at 11:31 AM Julien Rouhaud > wrote: > > > There's at least the current version of IVM patchset that lacks the > > > querytext. Looking at various extensions, I see

RE: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 12, 2020 at 10:31 AM, Julien Rouhaud wrote: > > * bufusage still only counts the buffer usage during executor. > > > > Now we have the ability to count the buffer usage during planner but we > keep > > the bufusage count the buffer usage during executor for now. > > The bufusage

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 12, 2020 at 1:11 PM Marco Slot wrote: > > On Thu, Mar 12, 2020 at 11:31 AM Julien Rouhaud wrote: > > There's at least the current version of IVM patchset that lacks the > > querytext. Looking at various extensions, I see that pg_background > > and pglogical call pg_plan_query

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 12, 2020 at 11:31 AM Julien Rouhaud wrote: > There's at least the current version of IVM patchset that lacks the > querytext. Looking at various extensions, I see that pg_background > and pglogical call pg_plan_query internally but shouldn't have any > issue providing the query text.

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 12, 2020 at 10:19 AM imai.yoshik...@fujitsu.com wrote: > > I'll summary code review of this thread. Thanks for the summary! I just have some minor comments > [Performance] > > If track_planning is not enabled, performance will drop 0.2-0.6% which can be > ignored. If track_planning

RE: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 12, 2020 at 6:31 AM, Julien Rouhaud wrote: > On Thu, Mar 12, 2020 at 05:28:38AM +, imai.yoshik...@fujitsu.com wrote: > > Hi Julien, > > > > On Mon, Mar 9, 2020 at 10:32 AM, Julien Rouhaud wrote: > > > On Thu, Mar 05, 2020 at 01:26:19PM -0700, legrand legrand wrote: > > > > Please

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi Imai-san, On Thu, Mar 12, 2020 at 05:28:38AM +, imai.yoshik...@fujitsu.com wrote: > Hi Julien, > > On Mon, Mar 9, 2020 at 10:32 AM, Julien Rouhaud wrote: > > On Thu, Mar 05, 2020 at 01:26:19PM -0700, legrand legrand wrote: > > > Please consider PG13 shortest path ;o) > > > > > > My one is

RE: Planning counters in pg_stat_statements (using pgss_store)

Hi Julien, On Mon, Mar 9, 2020 at 10:32 AM, Julien Rouhaud wrote: > On Thu, Mar 05, 2020 at 01:26:19PM -0700, legrand legrand wrote: > > Please consider PG13 shortest path ;o) > > > > My one is parse->queryId != UINT64CONST(0) in pgss_planner_hook(). > > It fixes IVM problem (verified), > > and

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Mar 05, 2020 at 01:26:19PM -0700, legrand legrand wrote: > Please consider PG13 shortest path ;o) > > My one is parse->queryId != UINT64CONST(0) in pgss_planner_hook(). > It fixes IVM problem (verified), > and keep CTAS equal to pgss without planning counters (verified too). I still

Re: Planning counters in pg_stat_statements (using pgss_store)

Never mind ... Please consider PG13 shortest path ;o) My one is parse->queryId != UINT64CONST(0) in pgss_planner_hook(). It fixes IVM problem (verified), and keep CTAS equal to pgss without planning counters (verified too). Regards PAscal -- Sent from:

Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Mar 2, 2020 at 1:01 PM legrand legrand wrote: > > Julien Rouhaud wrote > > On Sun, Mar 1, 2020 at 3:55 PM legrand legrand > > > > > legrand_legrand@ > > > wrote: > >> > >> >> I like the idea of adding a check for a non-zero queryId in the new > >> >> pgss_planner_hook() (zero queryid

Re: Planning counters in pg_stat_statements (using pgss_store)

Julien Rouhaud wrote > On Sun, Mar 1, 2020 at 3:55 PM legrand legrand > > legrand_legrand@ > wrote: >> >> >> I like the idea of adding a check for a non-zero queryId in the new >> >> pgss_planner_hook() (zero queryid shouldn't be reserved for >> >> utility_statements ?). >> >> > Some assert

Re: Planning counters in pg_stat_statements (using pgss_store)

On Sun, Mar 1, 2020 at 3:55 PM legrand legrand wrote: > > >> I like the idea of adding a check for a non-zero queryId in the new > >> pgss_planner_hook() (zero queryid shouldn't be reserved for > >> utility_statements ?). > > > Some assert hit later, I can say that it's not always true. For > >

Re: Planning counters in pg_stat_statements (using pgss_store)

>> I like the idea of adding a check for a non-zero queryId in the new >> pgss_planner_hook() (zero queryid shouldn't be reserved for >> utility_statements ?). > Some assert hit later, I can say that it's not always true. For > instance a CREATE TABLE AS won't run parse analysis for the

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi, On Fri, Feb 28, 2020 at 4:06 PM legrand legrand wrote: > > It seems IVM team does not consider this point as a priority ... Well, IVM is a big project and I agree that fixing this issue isn't the most urgent one, especially since there's no guarantee that this pgss planning patch will be

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi Julien, >> But I would have prefered this new feature to work the same way with or >> without track_planning activated ;o( > Definitely, but fixing the issue in pgss (ignoring planner calls when > we don't have a query text) means that pgss won't give an exhaustive > view of activity anymore,

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi, On Sat, Jan 18, 2020 at 6:14 PM legrand legrand wrote: > > Hi Julien, > > bot is still unhappy > https://travis-ci.org/postgresql-cfbot/postgresql/builds/638701399 > > portalcmds.c: In function ‘PerformCursorOpen’: > portalcmds.c:93:7: error: ‘queryString’ may be used uninitialized in this >

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi Julien, bot is still unhappy https://travis-ci.org/postgresql-cfbot/postgresql/builds/638701399 portalcmds.c: In function ‘PerformCursorOpen’: portalcmds.c:93:7: error: ‘queryString’ may be used uninitialized in this function [-Werror=maybe-uninitialized] plan = pg_plan_query(query,

Re: Planning counters in pg_stat_statements (using pgss_store)

On Sun, Jan 5, 2020 at 7:02 PM legrand legrand wrote: > > Julien Rouhaud wrote > > On Sun, Jan 5, 2020 at 4:11 PM legrand legrand > > > > > legrand_legrand@ > > > wrote: > >> > >> Hi Julien, > >> > >> I would like to create a link with > >> https://www.postgresql.org/message-id/ > > >

Re: Planning counters in pg_stat_statements (using pgss_store)

Julien Rouhaud wrote > On Sun, Jan 5, 2020 at 4:11 PM legrand legrand > > legrand_legrand@ > wrote: >> >> Hi Julien, >> >> I would like to create a link with >> https://www.postgresql.org/message-id/ > 1577490124579-0.post@.nabble >> >> where we met an ASSET FAILURE because query text was

Re: Planning counters in pg_stat_statements (using pgss_store)

On Sun, Jan 5, 2020 at 4:11 PM legrand legrand wrote: > > Hi Julien, > > I would like to create a link with > https://www.postgresql.org/message-id/1577490124579-0.p...@n3.nabble.com > > where we met an ASSET FAILURE because query text was not initialized ... > > The question raised is: > > -

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi Julien, I would like to create a link with https://www.postgresql.org/message-id/1577490124579-0.p...@n3.nabble.com where we met an ASSET FAILURE because query text was not initialized ... The question raised is: - should query text be always provided or - if not how to deal that case (in

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Nov 22, 2019 at 11:23 AM imai.yoshik...@fujitsu.com wrote: > > On Wed, Nov 20, 2019 at 4:55 PM, Julien Rouhaud wrote: > > On Wed, Nov 20, 2019 at 2:06 AM imai.yoshik...@fujitsu.com > > wrote: > > > > > > On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote: > > > > On Fri, Nov 15, 2019

RE: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Nov 20, 2019 at 4:55 PM, Julien Rouhaud wrote: > On Wed, Nov 20, 2019 at 2:06 AM imai.yoshik...@fujitsu.com > wrote: > > > > On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote: > > > On Fri, Nov 15, 2019 at 2:00 AM imai.yoshik...@fujitsu.com > > > wrote: > > > > > > > > Actually I

Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Nov 20, 2019 at 2:06 AM imai.yoshik...@fujitsu.com wrote: > > On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote: > > On Fri, Nov 15, 2019 at 2:00 AM imai.yoshik...@fujitsu.com > > wrote: > > > > > > Actually I also don't have strong opinion but I thought someone would > > >

RE: Planning counters in pg_stat_statements (using pgss_store)

On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote: > On Fri, Nov 15, 2019 at 2:00 AM imai.yoshik...@fujitsu.com > wrote: > > > > Actually I also don't have strong opinion but I thought someone would > > complain about renaming of those columns and > also some tools like monitoring which use

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Nov 15, 2019 at 2:00 AM imai.yoshik...@fujitsu.com wrote: > > Actually I also don't have strong opinion but I thought someone would > complain about renaming of those columns and also some tools like monitoring > which use those columns will not work. If we use {total, min, max, mean,

RE: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Nov 13, 2019 at 10:50 AM, Julien Rouhaud wrote: > On Tue, Nov 12, 2019 at 5:41 AM imai.yoshik...@fujitsu.com > wrote: > > > > On Sat, Nov 9, 2019 at 1:36 PM, Julien Rouhaud wrote: > > > > > > I attach v3 patches implementing those counters. > > > > Thanks for updating the patch! Now I

Re: Planning counters in pg_stat_statements (using pgss_store)

On Tue, Nov 12, 2019 at 5:41 AM imai.yoshik...@fujitsu.com wrote: > > On Sat, Nov 9, 2019 at 1:36 PM, Julien Rouhaud wrote: > > > > I attach v3 patches implementing those counters. > > Thanks for updating the patch! Now I can see min/max/mean/stddev plan time. > > > > Note that to avoid

RE: Planning counters in pg_stat_statements (using pgss_store)

On Sat, Nov 9, 2019 at 1:36 PM, Julien Rouhaud wrote: > On Fri, Nov 8, 2019 at 3:31 PM Julien Rouhaud wrote: > > > > On Fri, Nov 8, 2019 at 5:35 AM imai.yoshik...@fujitsu.com > > wrote: > > > > > > On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote: > > > > > [0002 patch] > > > > > In

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Nov 8, 2019 at 3:31 PM Julien Rouhaud wrote: > > On Fri, Nov 8, 2019 at 5:35 AM imai.yoshik...@fujitsu.com > wrote: > > > > On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote: > > > > [0002 patch] > > > > In pgss_planner_hook: > > > > > > > > + /* calc differences of

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Nov 8, 2019 at 5:35 AM imai.yoshik...@fujitsu.com wrote: > > On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote: > > > [0002 patch] > > > In pgss_planner_hook: > > > > > > + /* calc differences of buffer counters. */ > > > + bufusage =

RE: Planning counters in pg_stat_statements (using pgss_store)

On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote: > > [0002 patch] > > In pgss_planner_hook: > > > > + /* calc differences of buffer counters. */ > > + bufusage = compute_buffer_counters(bufusage_start, > > pgBufferUsage); > > + > > + /* > > +

Re: Planning counters in pg_stat_statements (using pgss_store)

Hello, On Sun, Sep 8, 2019 at 11:45 AM Imai Yoshikazu wrote: > > I also saw the codes and have one comment. Thanks for looking at this patch! > [0002 patch] > In pgss_planner_hook: > > + /* calc differences of buffer counters. */ > + bufusage =

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Sep 6, 2019 at 4:19 PM Tomas Vondra wrote: > > On Wed, Sep 04, 2019 at 07:19:47PM +0300, Sergei Kornilov wrote: > > > > ... > > > >Results: > > > > test | mode | average_tps | degradation_perc > >--+--+-+-- > >

Re: Planning counters in pg_stat_statements (using pgss_store)

Hello On 2019/09/06 23:19, Tomas Vondra wrote: > On Wed, Sep 04, 2019 at 07:19:47PM +0300, Sergei Kornilov wrote: >> >> ... >> >> Results: >> >>     test |   mode   | average_tps | degradation_perc >> --+--+-+-- >> head_no_pgss   

Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Sep 04, 2019 at 07:19:47PM +0300, Sergei Kornilov wrote: ... Results: test | mode | average_tps | degradation_perc --+--+-+-- head_no_pgss | extended | 13816 |1.000 patch_not_loaded

  1   2   >