On Tue, Jan 15, 2013 at 1:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas >> <hlinnakan...@vmware.com> wrote: >>> Could we stash the counter e.g. in the root page of the index? > >> That would require maintaining a counter per table rather than a >> single global counter, which would be bad because then we'd need to >> store one counter in shared memory for every table, rather than just >> one, period, which runs up against the fixed sizing of shared memory. > > I think what Heikki had in mind was that the copy in the index would be > the authoritative one, not some image in shared memory. This'd imply > dirtying the root page on every insert, as well as increased contention > for the root page, so it might have performance problems. > > I think a bigger issue is where we'd find any space for it. There's no > easily-spare space in a GIST page. This reminds me again that the lack > of a metapage in GIST was a serious design error, which we should > correct if we ever break on-disk compatibility again. > > I concur that adding such a counter to pg_control is a nonstarter, > though. > > Given that we don't need crash recovery for an unlogged table, could > we get away with some variant of NSN that has weaker semantics than > XLOG LSNs?
It needs to be strictly ascending and survive clean shutdowns. Is there some place we could preserve it other than the control file? I was assuming we wanted a single sequence shared across all relations rather than a sequence per relation, but I don't know of any reason why that's actually required. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
