|From:||Ekaterina Sokolova <e(dot)sokolova(at)postgrespro(dot)ru>|
|Subject:||Re: RFC: Logging plan of the running query|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 .
>> Does pg_query_state handle difficulties listed on the discussion?
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
> 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.
> 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.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|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?|