Re: compute_query_id and pg_stat_statements
От | Tom Lane |
---|---|
Тема | Re: compute_query_id and pg_stat_statements |
Дата | |
Msg-id | 1579535.1620930549@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: compute_query_id and pg_stat_statements (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: compute_query_id and pg_stat_statements
Re: compute_query_id and pg_stat_statements Re: compute_query_id and pg_stat_statements |
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > There's a ridiculously simple option here which is: drop the idea that > we support an extension redefining the query id and then just make it > on/off with the default to be 'on'. I do not think that defaulting it to 'on' is acceptable unless you can show that the added overhead is negligible. IIUC the measurements that have been done show the opposite. Maybe we should revert this thing pending somebody doing the work to make a version of queryid labeling that actually is negligibly cheap. It certainly seems like that could be done; one more traversal of the parse tree can't be that expensive in itself. I suspect that the performance problem is with the particular hashing mechanism that was used, which looks mighty ad-hoc anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: