Re: Make query ID more portable

Поиск
Список
Период
Сортировка
От Andrey Lepikhov
Тема Re: Make query ID more portable
Дата
Msg-id f8845cfb-4dcd-29f6-3a27-fd0ec29a5313@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Make query ID more portable  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On 14/10/21 10:40, Julien Rouhaud wrote:
> 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:
> 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.
Yes, and I use such custom decision too. But core jumbling code 
implements good idea and can be generalized for reuse. Patch from 
previous letter and breaking down of JumbleState can allow coders to 
implement their codes based on queryjumble.c module with smaller changes.

>  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.
My project is about adaptive query optimization techniques. It is not 
obvious how to match (without a field in Query struct) a post parse and 
an execution phases because of nested queries.
Also, if we use queryId in an extension, we interfere with 
pg_stat_statements.

-- 
regards,
Andrey Lepikhov
Postgres Professional



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber
Следующее
От: Aleksander Alekseev
Дата:
Сообщение: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column