Re: On-demand running query plans using auto_explain and signals

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
>
>