Re: Make query ID more portable - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Make query ID more portable
Date
Msg-id CAOBaU_bJJkaEhqbqFwQN3tNKBn8E2CZUUUj4MEo=OqtPkYF2Yg@mail.gmail.com
Whole thread Raw
In response to Re: Make query ID more portable  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Responses Re: Make query ID more portable  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
List pgsql-hackers
On Thu, Oct 14, 2021 at 12:37 PM Andrey Lepikhov
<a.lepikhov@postgrespro.ru> 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 <a.lepikhov@postgrespro.ru> 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 if an extension works only in the context of one
> node. But my efforts are directed to the cross-instance usage of a
> monitoring data. As an example, it may be useful for sharding.
> Also, I guess for an user is essential to think that if he changed a
> name of any object he also would change queries and reset monitoring
> data, related on this object.

What if someone wants to allow any form of partitioning without
changing to the ID, or ignore the schema because it's a multi tenant
db with dedicated roles?

I think that there are just too many arbitrary decisions that could be
made on what exactly should be a query identifier to have a single
in-core implementation.  If you do sharding, you already have to
properly configure each node, so configuring your custom query id
extension shouldn't be a big problem.



pgsql-hackers by date:

Previous
From: katouknl
Date:
Subject: Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion
Next
From: Andrey Lepikhov
Date:
Subject: Re: Make query ID more portable