Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 20210513.112629.407758843298621458.horikyota.ntt@gmail.com
Whole thread Raw
In response to compute_query_id and pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: compute_query_id and pg_stat_statements
List pgsql-hackers
At Thu, 13 May 2021 10:02:45 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in 
> On Thu, May 13, 2021 at 10:51:52AM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 13 May 2021 09:59:43 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> > > How about adding a GUC_INTERNAL "current_query_provider" or such?
> > 
> > On the second thought, I wonder why we don't just call JumbleQuery in
> > pgss_post_parse_analyze when compute_query_id is "off".
> 
> Because not generating a query_id for a custom query_id implementation is a
> valid use case for queries that are known to lead to huge pg_stat_statements
> overhead, as I mentioned in [1].  For the record I implemented that in
> pg_queryid (optionally don't generate query_id for queries referencing a temp
> relation) yesterday evening as a POC for that approach.

Yes, I know. So I said that "if not yet called".  I believe any "real"
alternative query-id provider is supposed to be hooked "before"
pg_stat_statements. (It is a kind of magic to control the order of
plugins, though..)  When the alternative provider generated a query_id
(that is, it has set jstate), pg_stat_statment doesn't call the
in-core JumbleQuery and uses the givin query_id.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance degradation of REFRESH MATERIALIZED VIEW
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: compute_query_id and pg_stat_statements