From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Christoph Berg <myon(at)debian(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: compute_query_id and pg_stat_statements |
Date: | 2021-05-15 08:09:32 |
Message-ID: | CAOBaU_bKJPm1k-2kPnoaRWK_7pTpRZxZtsnd+3dbayM53GYLFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 15, 2021 at 7:50 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> I took out the new WARNING in pg_stat_statements. It's not clear to me
> that that's terribly useful (it stops working as soon as you have one
> query in the pg_stat_statements stash and later disable everything).
If no query_id is calculated and you have entries in
pg_stat_statements, it means someone deliberately deactivated
compute_query_id. In that case it's clear that they know the GUC
exists, so there's no much point in warning them that they deactivated
it I think.
> Maybe there is an useful warning to add, but I think it's independent of
> changing the GUC behabior.
I'm fine with it.
> > Note that if you switch from compute_query_id = off + custom
> > query_id + pg_stat_statements to compute_query_id = auto then thing will
> > immediately break (as we instruct third-party plugins authors to error out in
> > that case), which is way better than breaking at the next random service
> > restart.
>
> Hmm, ok. I tested pg_queryid and that behavior of throwing an error
> seems quite unhelpful -- it basically makes every single query fail if
> you set things wrong. I think that instruction is bogus and should be
> reconsidered. Maybe pg_queryid could use a custom Boolean GUC that
> tells it to overwrite the core query_id if that is enabled, or to just
> silently do nothing in that case.
Unless I'm missing something, if we remove that instruction it means
that we encourage users to dynamically change the query_id source
without any safeguard, which will in the majority of case result in
unwanted behavior, going from duplicated entries, poor performance in
pg_stat_statements if that leads to more evictions, or even totally
bogus metrics if that leads to hash collision.
> While thinking about this patch it occurred to that an useful gadget
> might be to let pg_stat_statements be loaded always, but with
> compute_query_id=false; so it's never active; except if you
> ALTER {DATABASE, USER} foo SET (compute_query_id=on);
> so that it's possible to enable it selectively. I think this doesn't
> currently achieve anything because pgss_store is always called
> regardless of query ID being active (so you'd always have at least one
> function call as performance penalty, only that the work would be for
> naught), but that seems a simple change to make. I didn't look closely
> to see what other things would need patched.
Couldn't it already be achieved with ALTER [ DATABASE | USER ] foo SET
pg_stat_statements.track = [ none | top | all ] ?
From | Date | Subject | |
---|---|---|---|
Next Message | Nitin Jadhav | 2021-05-15 09:10:45 | Removed extra memory allocations from create_list_bounds |
Previous Message | Joel Jacobson | 2021-05-15 06:51:46 | Re: use AV worker items infrastructure for GIN pending list's cleanup |