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
