Re: Planning counters in pg_stat_statements (using pgss_store)

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, "imai(dot)yoshikazu(at)fujitsu(dot)com" <imai(dot)yoshikazu(at)fujitsu(dot)com>, legrand legrand <legrand_legrand(at)hotmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
Date: 2021-07-25 16:36:37
Message-ID: 20210725163637.qkslpe24mgzen73t@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 flushes can happen for other reasons,
> it's my guess that this test case would prove unstable in the buildfarm
> even without considering the CLOBBER_CACHE_ALWAYS members. For example,
> a background autovacuum hitting the "test" table at just the right time
> would result in extra planning. We haven't seen that because the
> buildfarm's not running this test, but that's about to change.


> 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?

I think we should go with the latter. Checking for a legit value, even if it's
a bit imprecise is still better than nothing.

Would it be worth to split the query for the prepared statement row vs the rest
to keep the full "plans" coverage when possible?

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-07-25 16:59:35 Re: Planning counters in pg_stat_statements (using pgss_store)
Previous Message Tom Lane 2021-07-25 16:28:04 Re: Removing "long int"-related limit on hash table sizes