Tom Lane wrote:
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > Also I am worried about the performance of the per table Oid
> > generators.
>
> I think performance would be a big problem if we tried to implement them
> just like sequences are done now. But a shared hashtable of Oid
> generators (each one handled roughly like the single Oid generator
> currently is) would probably work okay. We'd have to work out how to
> have a backing disk table for this hashtable, since we couldn't expect
> to have room in shared memory for all generators at all times --- but we
> could cache all the active generators in shared memory, I'd think.
Maybe I'm confused, is there no shared memory for each unique table in use?
If so, couldn't the Oid generator be stored there? if not, how does that
work?
Second, IMHO I think you are a bit too conservative with shared memory. If
one has so many active tables that their Oid generators wouldn't fit in
shared memory, this would indicate a fairly large database, I think one
could be justified in requiring more resources than the minimum. PostgreSQL
is already increasing in resource requirements. The introduction of WAL
added a lot of disk space for operation. A few K of shared RAM doesn't seem
like a lot. (Maybe I am jaded as I have bumped my shared memory to 128M)
Lastly, were PostgreSQL to have multiple Oid generators, each of these
could have its own spinlock or mutex, thus reducing competition. In an
active system with activity on multiple tables, this could improve
performance.