On 14/10/21 10:40, Julien Rouhaud wrote:
On Thu, Oct 14, 2021 at 12:37 PM Andrey Lepikhov
wrote:
On 12/10/21 18:45, Bruce Momjian wrote:
On Tue, Oct 12, 2021 at 09:40:47AM -0400, Tom Lane wrote:
Andrey Lepikhov writes:
I think that there are just too many arbitrary decisions that could be
On 12/10/21 18:40, Tom Lane wrote:
Andrey Lepikhov writes:
But core jumbling code is good, fast and much easier in support.
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 Q
On Thu, Oct 14, 2021 at 12:37 PM Andrey Lepikhov
wrote:
>
> On 12/10/21 18:45, Bruce Momjian wrote:
> > On Tue, Oct 12, 2021 at 09:40:47AM -0400, Tom Lane wrote:
> >> Andrey Lepikhov writes:
> >>> But core jumbling code is good, fast and much easier in support.
> > Also, the current code handles
On 12/10/21 18:45, Bruce Momjian wrote:
On Tue, Oct 12, 2021 at 09:40:47AM -0400, Tom Lane wrote:
Andrey Lepikhov writes:
But core jumbling code is good, fast and much easier in support.
Also, the current code handles renames of schemas and objects, but this
would not.
Yes, It is good option
On Tue, Oct 12, 2021 at 09:40:47AM -0400, Tom Lane wrote:
> Andrey Lepikhov 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
>
Andrey Lepikhov 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 tha
On 12/10/21 13:35, Julien Rouhaud wrote:
Hi,
On Tue, Oct 12, 2021 at 4:12 PM Andrey V. Lepikhov
wrote:
See the patch in attachment as an POC. Main idea here is to break
JumbleState down to a 'clocations' part that can be really interested in
a post parse hook and a 'context data', that needed
Hi,
On Tue, Oct 12, 2021 at 4:12 PM Andrey V. Lepikhov
wrote:
>
> QueryID is good tool for query analysis. I want to improve core jumbling
> machinery in two ways:
> 1. QueryID value should survive dump/restore of a database (use fully
> qualified name of table instead of relid).
> 2. QueryID cou
Hi,
QueryID is good tool for query analysis. I want to improve core jumbling
machinery in two ways:
1. QueryID value should survive dump/restore of a database (use fully
qualified name of table instead of relid).
2. QueryID could represent more general class of queries: for example,
it can be
