> From: "Tsunakawa, Takayuki"
>> From: legrand legrand [mailto:legrand_legrand@]
>> There are many projects that use alternate QueryId
>> distinct from the famous pg_stat_statements jumbling algorithm.
>I'd like to welcome the standard QueryID that DBAs and extension developers
can depend on.
>Are you surveying the needs for you to develop the QueryID that can meet as
many needs as possible?
Yes, I would like first to understand what are the main needs,
then identify how it would be possible to implement it
in core, in a new extension or simply with a modified pg_stat_statements.
(I'm just a DBA not a C developer, so it will only be restricted to very
simple enhancements)
>> needs.1: stable accross different databases,
>Does this mean different database clusters, not different databases in a
single database cluster?
Same looking query should give same QueryId on any database (in the same
cluster or in distinct clusters). It can be differentiated with dbid.
>needs.5: minimal overhead to calculate
OK will add it
>needs.6: doesn't change across database server restarts
Really ? does this already occurs ?
>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 ?
>> norm.9: comments aware
>Is this to distinguish queries that have different comments for optimizer
hints? If yes, I agree.
Yes and others like playing with :
set ...
select /* test 1*/ ...
set ...
select /* test 2*/ ...
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html