From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Artur Zając <azajac@ang.com.pl>
Cc: pgsql-performance@postgresql.org
Subject: Re: NOTIFY performance
Date: Fri, 31 Aug 2012 16:22:59 -0400
Message-ID: <18884.1346444579@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMkU=1x-6Q2gG6muiUWHzoUkYMQePS52hds6D=VjF3RvxppT5g@mail.gmail.com>
References: <002401cd8228$ce80e970$6b82bc50$@ang.com.pl>
<CAMkU=1x-6Q2gG6muiUWHzoUkYMQePS52hds6D=VjF3RvxppT5g@mail.gmail.com>
Jeff Janes <jeff.janes@gmail.com> writes:
> I wonder if should be trying to drop duplicates at all. I think that
> doing that made a lot more sense before payloads existed.
Perhaps, but we have a lot of history to be backwards-compatible with.
> The docs said that the system "can" drop duplicates, so making it no
> longer do so would be backwards compatible.
Maybe compatible from a language-lawyerly point of view, but the
performance characteristics would be hugely different - and since this
complaint is entirely about performance, I don't think it's fair to
ignore that. We'd be screwing people who've depended on the historical
behavior to accommodate people who expect something that never worked
well before to start working well.
The case that I'm specifically worried about is rules and triggers that
issue NOTIFY without worrying about generating lots of duplicates when
many rows are updated in one command.
> Maybe drop duplicates where the payload was the empty string, but keep
> them otherwise?
Maybe, but that seems pretty weird/unpredictable. (In particular, if
you have a mixed workload with some of both types of notify, you lose
twice: some of the inserts will need to scan the list, so that cost
is still quadratic, but you still have a huge event list to dump into
the queue when the time comes.)
I seem to recall that we discussed the idea of checking only the last N
notifies for duplicates, for some reasonably small N (somewhere between
10 and 100 perhaps). That would prevent the quadratic behavior and yet
also eliminate dups in most of the situations where it would matter.
Any N>1 would require a more complicated data structure than is there
now, but it doesn't seem that hard.
The other thing we'd need to find out is whether that's the only problem
for generating bazillions of notify events per transaction. It won't
help to hack AsyncExistsPendingNotify if dropping the events into the
queue is still too expensive. I am worried about the overall processing
cost here, consumers and producers both.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, jeff.janes@gmail.com, azajac@ang.com.pl
Subject: Re: NOTIFY performance
In-Reply-To: <18884.1346444579@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox