Re: [survey] New "Stable" QueryId based on normalized query text

Julien Rouhaud wrote
> On Wed, Mar 20, 2019 at 8:39 PM legrand legrand
> <

> legrand_legrand@

> > wrote:
>>
>> Yes, I would like first to understand what are the main needs,
>
> I don't really see one implementation that suits every need, as
> probably not everyone will agree on using relation name vs fully
> qualified relation name for starter. The idea to take into account or
> normalise comments will also probably require a lot of argumentation
> to reach a consensus.
>
> Also, most of what's listed here would require catcache lookup for
> every objects impacted in a query, at every execution. That would be
> *super* expensive (at least for OLTP workload). As far as the need is
> to gather statistics like pg_stat_statements and similar extensions
> are doing, current queryid semantics and underlying limitations is not
> enough of a problem to justify paying that price IMHO. Or do you have
> other needs and/or problems that really can't be solved with current
> implementation?
>
> In other words, my first need would be to be able to deactivate
> everything that would make queryid computation significantly more
> expensive than it's today, and/or to be able to replace it with
> third-party implementation.
>
>> >> needs.1: stable accross different databases,
>> [...]
>>
>> >needs.7: same value on both the primary and standby?
>>
>> I would say yes (I don't use standby) isn't this included into needs.1 ?
>
> Physical replication servers have identical oids, so identical
> queryid. That's obviously not true for logical replication.

On my personal point of view, I need to get the same Queryid between (OLAP)
environments
to be able to compare Production, Pre-production, Qualif performances
(and I don't need Fully qualified relation names). Today to do that,
I'm using a custom extension computing the QueryId based on the normalized
Query
text.

This way to do, seems very popular and maybe including it in core (as a
dedicated extension)
or proposing an alternate queryid (based on relation name) in PGSS (Guc
enabled)
would fullfill 95% of the needs ...

I agree with you on the last point: being able to replace actual QueryId
with third-party
implementation IS the first need.

Regards
PAscal

--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html