Date: Wed, 20 Mar 2019 14:17:59 -0700 (MST)
From: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-hackers@postgresql.org
Message-ID: <1553116679891-0.post@n3.nabble.com>
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>
Subject: Re: [survey] New "Stable" QueryId based on normalized query text
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

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

> legrand_legrand@

> &gt; 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