On Wed, Mar 20, 2019 at 8:39 PM legrand legrand
<legrand_legrand@hotmail.com> 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.