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

2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr <oleksandr(dot)shulgin(at)zalando(dot)de>
:

> On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
> the preparing of content before execution is interesting idea, that can be
>> used more. The almost queries and plans are not too big, so when the size
>> of content is not too big - less than 1MB, then can be used one DSM for all
>> backends.
>>
>
>
>> When size of content is bigger than limit, then DSM will be allocated
>> specially for this content. The pointer to DSM and offset can be stored in
>> requested process slot. The reading and writing to requested slot should be
>> protected by spinlock, but it should block only two related processes for
>> short time (copy memory).
>>
>
> Sorry, I don't think this will fly.
>
> The whole idea is that a backend publishes the plan of a query just before
> running it and it doesn't care which other backend(s) might be reading it,
> how many times and in which order. The only required locking (implicit) is
> contained in the code for dsm_attach/detach().
>

I didn't propose too different solution. There is only one difference -
sharing DSM for smaller data. It is similar to using usual shared memory.

Regards

Pavel

>
>
>> Other possibility is showing the size of content in requested process
>> slot. Then the requester can preallocate enough size of shared memory. But
>> this doesn't solve a issues related to waiting requester for content. So
>> first variant is pretty simple, and should be preferred. The disadvantage
>> is clear - it can enforce maybe significant slowdown of fast queries.
>>
>
> Both of these approaches have just too many synchronization problems, IMO.
>
> --
> Alex
>
>