Re: RFC: Logging plan of the running query

From: Ekaterina Sokolova <e(dot)sokolova(at)postgrespro(dot)ru>
To: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: RFC: Logging plan of the running query
Date: 2021-11-02 11:32:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


I'm here to answer your questions about contrib/pg_query_state.
>> I only took a quick look at pg_query_state, I have some questions.

>> pg_query_state seems using shm_mq to expose the plan information, but
>> there was a discussion that this kind of architecture would be tricky
>> to do properly [1].
>> Does pg_query_state handle difficulties listed on the discussion?
> [1]

I doubt that it was the right link.
But on the topic I will say that extension really use shared memory,
interaction is implemented by sending / receiving messages. This
architecture provides the required reliability and convenience.

>> It seems the caller of the pg_query_state() has to wait until the
>> target process pushes the plan information into shared memory, can it
>> lead to deadlock situations?
>> I came up with this question because when trying to make a view for
>> memory contexts of other backends, we encountered deadlock situations.
>> After all, we gave up view design and adopted sending signal and
>> logging.
> Discussion at the following URL.

Before extracting information about side process we check its state.
Information will only be retrieved for a process willing to provide it.
Otherwise, we will receive an error message about impossibility of
getting query execution statistics + process status. Also checking fact
of extracting your own status exists. This is even verified in tests.

Thanks for your attention.
Just in case, I am ready to discuss this topic in more detail.

About overhead:
> I haven't measured it yet, but I believe that the overhead for backends
> which are not called pg_log_current_plan() would be slight since the
> patch just adds the logic for saving QueryDesc on ExecutorRun().
> The overhead for backends which is called pg_log_current_plan() might
> not slight, but since the target process are assumed dealing with
> long-running query and the user want to know its plan, its overhead
> would be worth the cost.
I think it would be useful for us to have couple of examples with a
different number of rows compared to using without this functionality.

Hope this helps.

Ekaterina Sokolova
Postgres Professional:
The Russian Postgres Company


Browse pgsql-hackers by date

  From Date Subject
Next Message gkokolatos 2021-11-02 11:36:49 Re: Teach pg_receivewal to use lz4 compression
Previous Message Himanshu Upadhyaya 2021-11-02 11:19:57 Should we support new definition for Identity column : GENERATED BY DEFAULT ON NULL?