From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joachim Wieland <joe(at)mcknight(dot)de>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Chernow <andrew(at)esilo(dot)com> |
Subject: | Re: Listen / Notify rewrite |
Date: | 2009-11-13 15:00:15 |
Message-ID: | 4AFD747F.3080903@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-13 15:01:59 | Re: Aggregate ORDER BY patch |
Previous Message | Andrew Dunstan | 2009-11-13 14:52:00 | Re: next CommitFest |