Re: Listen / Notify rewrite
От | Andrew Chernow |
---|---|
Тема | Re: Listen / Notify rewrite |
Дата | |
Msg-id | 4AFD747F.3080903@esilo.com обсуждение исходный текст |
Ответ на | Re: Listen / Notify rewrite (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Listen / Notify rewrite
|
Список | pgsql-hackers |
>> 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. Not having the payload at all is like santa showing up without his bag of toys. Instead, you have to drive/fly to the north pole where he just came from to get them. > > 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. > I think the original OP was close. The structure can still be fixed length but maybe we can bump it to 8k (BLCKSZ)? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
В списке pgsql-hackers по дате отправления: