Re: Listen / Notify rewrite
От | Merlin Moncure |
---|---|
Тема | Re: Listen / Notify rewrite |
Дата | |
Msg-id | b42b73150911130516y27bbd330qd7a865b5813bf4f7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Listen / Notify rewrite (Greg Stark <gsstark@mit.edu>) |
Список | 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
В списке pgsql-hackers по дате отправления: