From: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-hackers@postgresql.org
Subject: Re: [survey] New "Stable" QueryId based on normalized query text
Date: Wed, 20 Mar 2019 14:17:59 -0700 (MST)
Message-ID: <1553116679891-0.post@n3.nabble.com> (raw)
In-Reply-To: <CAOBaU_ZJShkK40_suw9NtUZEtoM07PYg4c_G2m_=HyXQ+pzoAw@mail.gmail.com>
References: <1553029215728-0.post@n3.nabble.com>
<0A3221C70F24FB45833433255569204D1FBE20A4@G01JPEXMBYT05>
<1553110765067-0.post@n3.nabble.com>
<CAOBaU_ZJShkK40_suw9NtUZEtoM07PYg4c_G2m_=HyXQ+pzoAw@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: legrand_legrand@hotmail.com
Subject: Re: [survey] New "Stable" QueryId based on normalized query text
In-Reply-To: <1553116679891-0.post@n3.nabble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox