On Mon, Feb 13, 2012 at 9:41 AM, Andres Freund <andres@anarazel.de> wrote:
> On Monday, February 13, 2012 02:08:08 PM Robert Haas wrote:
>> On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> > Yeh, I was thinking we would do well to implement cached sequences for
>> > say first 1000 sequences.
>>
>> Another option might be to store all the sequences for a particular
>> database in a single underlying data file. The current implementation
>> uses a whole page for a single tuple that is presumably much smaller
>> than that. So when you create a sequence "foo", it's really creating
>> a row in some new system catalog pg_sequences, or something like that.
> I wonder if the tigher packing would be noticeable contentionwise.... If
> several hot sequences end up in a single page that could end up being
> measurable.
For the contention to really be an issue, you'd need a very high rate
of access to that sequence - in my tests so far, the only things that
seem to get hot enough to really hurt are the roots of btrees and
visibility map pages. And on the plus side, you'd be reducing the
number of pages fighting to stay in shared_buffers. That having been
said, it's something to watch out for - I certainly don't know enough
to say for certain that it wouldn't be a problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
