From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: On-demand running query plans using auto_explain and signals |
Date: | 2015-09-01 13:09:52 |
Message-ID: | CAFj8pRDbaxahTrs7BU+_=UJeDufXP119BSo0cJjB5FZfvbhVvQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2015-09-01 15:00 GMT+02:00 Shulgin, Oleksandr <oleksandr(dot)shulgin(at)zalando(dot)de>
:
> I'd say we should hide the so-designed pg_cmdstatus() interface behind
>>> more friendly calls like pg_explain_backend() and pg_backend_progress() to
>>> give some naming examples, to remove the need for magic numbers in the
>>> second arg.
>>>
>>
>> I had similar idea - this is good enough for start, but target interface
>> iis based on integration with EXPLAIN statement
>>
>> some like EXPLAIN PROCESS or EXPLAIN PID or EXPLAIN VERBOSE PID ..
>>
>
> Yes, that's another way to do it.
>
> the important functionality is drawing complete text of query - it was my
>> original motivation, because I had not way how to get complete query before
>> its finishing
>>
>> Probably the communication between processes should be more complex :( -
>> the SHM queue should be used there, because some plans can be terrible long.
>>
>> The using shared write buffer (one for all) is too simply solution
>> probably - good for prototype, but not good for core.
>>
>> I have a idea about communication:
>>
>> 1. caller prepare buffer, shm queue and signalize target process -
>> parameter is pid od caller
>> 2. target process fills a write buffer and close queue
>> 3. caller show data and close buffer, close queue
>>
>> Now almost all code for communication is in upstream - the missing part
>> is injection one end of queue to any process dynamicaly.
>>
>
> I'm not familiar with the shared memory handling, but could we not
> allocate just enough shared memory to fit the data we're going to write
> instead of the fixed 8k? It's not that we cannot know the length of the
> resulting plan text in advance.
>
the shared memory cannot be reused - (released) :(, so allocating enough
memory is not effective. More - in this moment it has not sense. Shared
memory queue can do almost all work.
>
> I think we can remove buffer_is_free/buffer_holds_data and just use the
> buffer != NULL to check if there's some data to be read (and buffer == NULL
> to check if we can write).
>
> --
> Alex
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-09-01 13:41:56 | Re: WIP: About CMake v2 |
Previous Message | Shulgin, Oleksandr | 2015-09-01 13:00:58 | Re: On-demand running query plans using auto_explain and signals |