| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Jim Finnerty <jfinnert(at)amazon(dot)com> |
| Subject: | Re: Make query ID more portable |
| Date: | 2021-10-12 13:40:47 |
| Message-ID: | 570860.1634046047@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> writes:
> But core jumbling code is good, fast and much easier in support.
It won't be fast once you stick a bunch of catalog lookups into it.
I think this is fine as an extension, but it has no chance of being
accepted in core, just on performance grounds.
(I'm also not sure that the query ID calculation code is always/only
invoked in contexts where it's safe to do catalog accesses.)
A bigger issue is that query ID stability isn't something we are going
to promise on a large scale --- for example, what if a new release adds
some new fields to struct Query? So I'm not sure that "query IDs should
survive dump/reload" is a useful goal to consider. It's certainly not
something that could be reached by anything even remotely like the
existing code.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2021-10-12 13:45:41 | Re: Make query ID more portable |
| Previous Message | Peter Eisentraut | 2021-10-12 13:30:57 | Re: [RFC] building postgres with meson |