Marko Tiikkaja <marko@joh.to> writes:
> On 11/19/15 4:21 PM, Tom Lane wrote:
>> ... and then you gotta get the notifications to the clients, so it seems
>> like this just leaves the performance question hanging.
> I'm not sure which performance question you think is left hanging. If
> every client is connected to postgres, you're waking up tens if not
> hundreds of processes tens if not hundreds of times per second. Each of
> them start a transaction, check which notifications are visible in the
> queue from clog and friends, go through the tails of every other process
> to see whether they should advance the tail pointer of the queue, commit
> the transaction and go back to sleep only to be immediately woken up again.
> If they're not connected to postgres directly, this kind of complex
> processing only happens once, and then the notification server just
> unconditionally serves all notifications to the clients based on a
> simple map lookup. It should be trivial to see how the overhead is avoided.
Meh. You've gotten rid of one single-point-of-contention by creating
another one. Essentially, your argument why this is an improvement is
that any random application developer using Postgres is smarter than
the Postgres development team and can therefore produce something
better-performing off the cuff. Which may indeed be true, but shall we
say it's unproven?
I don't buy the argument about removing transactional overhead, either.
The point of LISTEN/NOTIFY is to inform clients that something has
happened in the database that they ought to react to. So necessarily,
there's going to be follow-on database activity. If you're using
LISTEN/NOTIFY to wake up clients who otherwise wouldn't need a DB
connection at all, then you chose the wrong signaling mechanism.
>> In any case, it would be good to understand exactly what's the performance
>> issue that's biting you. Can you provide a test case that reproduces
>> that behavior?
> I've attached a Go program which simulates quite accurately the
> LISTEN/NOTIFY-part of our setup. What it does is:
Thanks, I'll take a look later.
regards, tom lane
