On Mon, Feb 13, 2012 at 9:41 AM, Andres Freund <and...@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 <si...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers