Re: Listen / Notify rewrite - Mailing list pgsql-hackers

On Fri, Nov 13, 2009 at 5:35 AM, Greg Stark <gsstark@mit.edu> wrote:
> On Fri, Nov 13, 2009 at 1:57 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I agree.  We frequently reject features on the basis that someone
>> might do something stupid with them.  It's lame and counterproductive,
>> and we should stop.  The world contains infinite amounts of lameness,
>> but that's the world's problem, not ours.  There is zero evidence that
>> this feature is only useful for stupid purposes, and some evidence
>> (namely, the opinions of esteemed community members) that it is useful
>> for at least some non-stupid purposes.
>
> This is BS. The problem is not that someone might do something stupid
> with this feature. The problem is that we're making these other use
> cases into requirements which will influence the design. This is a
> classic "feature creep" situation and the result is normally products
> which solve none of the use cases especially well.

Removing a length restriction is feature creep?

Having an flexible payload mechanism improves on notify in the same
way that epoll improves on poll.   Yes, epoll is overdesigned, highly
overused, etc. but it does vastly improve server
handling/responsiveness in some situations.  Delivering a notification
with data saves a round trip back to the server and a transaction
which is both helpful in terms of server load and improving latency.
On top of that, I don't think saying: "hello; here's some data" is
groundbreaking in terms of network communication paradigms.

My interest in this feature is not academic, the project I'm working
on could use it with great benefit immediately. Arguments that I am
using notify for the set list of use cases improvised by the original
authors are not going to hold much water with me :-).

IMNSHO, I don't think that keeping payloads limited to a tiny size
'improves' this feature is a winnable argument.  That said, I do
appreciate simple designs and very much understand trying to keep
things simple.  So let me ask you this:

*) Are you sure that putting a variable length payload into the slru
is going to complicate things that badly in terms of implementing this
feature?  If so, how?

*) Wouldn't you agree that variable length would actually benefit
'proper' (small) payloads by allowing more of them to fit in the slru
page?

*) 8k should be enough for anybody :-) ...so if a variable length
structure can be made why not max the payload length at blcksz-hdrsz
and call it a day (yes, I am aware that extending the structure will
reduce payload maximum length)? I think this should fit quite nicely
into the OP's approach and benefits both people who use small payloads
and large ones...(I DO think spanning pages is complex and probably
unnecessary)

merlin