Re: pg_stat_statements query jumbling question
От | Michael Paquier |
---|---|
Тема | Re: pg_stat_statements query jumbling question |
Дата | |
Msg-id | CAB7nPqSj8uaBJzgqMAJVGMjGLWUkFf-u1+v2Ow3wLdw2f5n_WA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_statements query jumbling question (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sun, Nov 15, 2015 at 1:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Sun, Nov 1, 2015 at 2:03 AM, Julien Rouhaud >> <julien.rouhaud@dalibo.com> wrote: >>> I'm also rather sceptical about this change. > >> Hm. Thinking a bit about this patch, it presents the advantage to be >> able to track the same queries easily across systems even if those >> tables have been created with a different OID. > > That argument would only hold if *every* use of OIDs in the jumbles > were replaced by names --- not only tables, but types, operators, > functions, etc. I'm already concerned that the additional name > lookups will cost a lot of performance, and I think adding so many > more would probably be disastrous. Yeah, I was thinking about a GUC switch to change from one mode to another yesterday night before sleeping. Now if there was a patch actually implementing that, and proving that this has no performance impact, well I think that this may be worth considering for integration. But we're far from that >> Also, isn't this patch actually broken if we rename relations and/or >> its namespace? > > Well, it would mean that the query would no longer be considered "the > same". You could argue either way whether that's good or bad. But > yeah, this approach will break one set of use-cases to enable another > set. > > On the whole, I think my vote is to reject this patch. Agreed. It's clear that the patch as-is is not enough. -- Michael
В списке pgsql-hackers по дате отправления: