> 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
