st 17. 3. 2021 v 17:03 odesÃlatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Bruce Momjian <br...@momjian.us> writes: > > On Wed, Mar 17, 2021 at 11:28:38AM -0400, Tom Lane wrote: > >> I still say that it's a serious mistake to sanctify a query ID > calculation > >> method that was designed only for pg_stat_statement's needs as the one > >> true way to do it. But that's what exposing it in a core view would do. > > > OK, I am fine with creating a new method, and maybe having > > pg_stat_statements use it. Is that the direction we should be going in? > > The point is that we've understood Query.queryId as something that > different extensions might calculate differently for their own needs. > In particular it's easy to imagine extensions that want an ID that is > less fuzzy than what pg_stat_statements wants. We never had a plan for > how two such extensions could co-exist, but at least it was possible > to use one if you didn't use another. If this gets moved into core > then there will basically be only one way that anyone can do it. > > Maybe what we need is a design for allowing more than one query ID. > Theoretically there can be a hook for calculation of queryid, that can be by used extension. Default can be assigned with a method that is used by pg_stat_statements. I don't think it is possible to use more different query id for pg_stat_statements so this solution can be simple. regards Pavel > > > I do think we need _some_ method in core if we are going to be exposing > > this value in pg_stat_activity and log_line_prefix. > > I'm basically objecting to the conclusion that we should do either > of those. There is no way around the fact that it will break every > user of Query.queryId other than pg_stat_statements, unless they > are okay with whatever definition pg_stat_statements is using (which > is a moving target BTW). > > regards, tom lane > > >
