Re: On-demand running query plans using auto_explain and signals - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: On-demand running query plans using auto_explain and signals
Date
Msg-id CACACo5Qfk4U5wacm_0_kCgSBHnFDmHOMqiYLjV8=x_MwSHCK9g@mail.gmail.com
Whole thread Raw
In response to Re: On-demand running query plans using auto_explain and signals  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: On-demand running query plans using auto_explain and signals  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Mon, Sep 28, 2015 at 7:09 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr <oleksandr.shulgin@zalando.de>:

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.

Does this mean implementing some sort of allocator on top of the shared memory segment?  If so, how are you going to prevent fragmentation?

yes, simple memory allocator is necessary in this case. But it should be really simple - you can allocate only fixed size blocks - 10KB, 100KB and 1MB from separate buffers. So the fragmentation is not possible.

Maybe we're talking about completely different ideas, but I don't see how fixing the block helps to fight fragmentation, in particular.  Can you sketch a simple example?  E.g. 400 backends share the common segment and all of them want to publish a plan of ~1kb, for example.  Now what?

--
Alex

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: On-demand running query plans using auto_explain and signals
Next
From: Pavel Stehule
Date:
Subject: Re: On-demand running query plans using auto_explain and signals