Horton

Re: compute_query_id and pg_stat_statements

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: magnus@hagander.net, masao.fujii@oss.nttdata.com, michael@paquier.xyz, andres@anarazel.de, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, sfrost@snowman.net, bruce@momjian.us, myon@debian.org, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Date: 2021-05-13T01:42:28Z
Lists: pgsql-hackers 
On Thu, May 13, 2021 at 09:59:43AM +0900, Kyotaro Horiguchi wrote:
> 
> The query_id of its own is provided because pg_stat_statements did not
> expose query_id. And it has been preserved only for the case the
> plugin is used without pg_stat_statements activated.  Now that the
> in-core query_id is available, the last reason for the special
> provider has gone.

Ah I see, indeed that makes sense.  However I'm assuming that pg_store_plans
also requires *a* queryid, not specifically what used to be pg_stat_statements'
one right, so it could also fallback on an alternative implementation if users
configured one?  Even if that's not the case, the core query_id can still be
calculated if needed as the function is now exported.

Commits

  1. Allow compute_query_id to be set to 'auto' and make it default

  2. Move pg_stat_statements query jumbling to core.