On Fri, Nov 13, 2009 at 1:47 PM, Andrew Chernow <a...@esilo.com> wrote: > This is what I think the people's real problem is, the implementation > becomes a more complex when including payloads (larger ones even more so). > I think its a side-track to discuss queue vs condition variables. Whether > a notify is 20 bytes through the network or 8192 bytes doesn't change its > design or purpose, only its size. > > Calling this a creeping feature is quite a leap.
It's true that the real creep is having the payload at all rather than not having it. But having fixed-size data also makes the implementation much simpler as well. One person described stuffing the payload with the primary key of the record being invalidated. This means the requirements have just gone from holding at most some small fixed number of records bounded by the number of tables or other shared data structures to holding a large number of records bounded only by the number of records in their tables which is usually much much larger. Now you're talking about making the payloads variable size, which means you need to do free space management within shared pages to keep track of how much space is free and available for reuse. So we've gone from a simple hash table of fixed size entries containing an oid or "name" datum where we expect the hash table to fit in memory and a simple lru can handle old pages that aren't part of the working set to something that's going to look a lot like a database table -- it has to handle reusing space in collections of variable size data and scale up to millions of entries. And I note someone else in the thread was suggesting it needed ACID properties which makes space reuse even more complex and will need something like vacuum to implement it. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers