Igor Neyman <iney...@perceptron.com> writes:
>> [ shrug... ] It was debated extensively and the advantages of the new
>> implementation were deemed to outweigh the disadvantages.
> Are you saying that these two features: attached payload and being able to
> find which channels are being listened to - are incompatible? That they
> cannot coexist?
It's not about the payload aspect. We got rid of the use of a table to
store messages-in-transit, which resulted in greatly improved throughput
and lower overhead --- but it also means that there's no exposed
information about which backends are actually paying attention to
specific notify channels. We could have bolted some overhead back on
to expose that again, but it was judged that too few people had that
requirement to justify imposing such overhead on everybody. The
infrequency of complaints in the two years since then seems to justify
that choice.
It's not particularly difficult to create your own signaling system
for this purpose, if you think it's worth the trouble --- LISTEN just
doesn't have it built in anymore. In practice, I'll bet it's not worth
the trouble versus just firing off messages unconditionally.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
