| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'legrand legrand' <legrand_legrand(at)hotmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: [survey] New "Stable" QueryId based on normalized query text |
| Date: | 2019-03-20 00:23:30 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FBE20A4@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: legrand legrand [mailto:legrand_legrand(at)hotmail(dot)com]
> 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?
> needs.1: stable accross different databases,
Does this mean different database clusters, not different databases in a single database cluster?
needs.5: minimal overhead to calculate
needs.6: doesn't change across database server restarts
needs.7: same value on both the primary and standby?
> norm.9: comments aware
Is this to distinguish queries that have different comments for optimizer hints? If yes, I agree.
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2019-03-20 00:41:43 | Re: speeding up planning with partitions |
| Previous Message | Kyotaro HORIGUCHI | 2019-03-20 00:03:45 | Re: Proposal to suppress errors thrown by to_reg*() |