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

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
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 15:20:42
Message-ID: CACACo5Rus7eoL4kHv6uSyOi3m7ATyykej3DJsL4RrTbCO+Sb9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

A-ha, I've discovered the shared memory message queue facility and I see
how we can use it.

But do we really need the slots mechanism? Would it not be OK to just let
the LWLock do the sequencing of concurrent requests? Given that we only
going to use one message queue per cluster, there's not much concurrency
you can gain by introducing slots I believe.

--
Alex

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-09-01 15:26:27 Re: perlcritic
Previous Message Joshua D. Drake 2015-09-01 15:20:12 Re: Horizontal scalability/sharding