Re: OID wraparound: summary and proposal

Tom Lane wrote:
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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.

Keep also in mind that actually the uniqueness of Oid's
across all tables is used by TOAST to determine that a
toasted value found in the new tuple is the same than in the
old one on heap_update() or not. If we go for a separate Oid
per table, an UPDATE with a subselect from another table
could get misinterpreted in the toaster, not duplicating the
value but referencing the external value in another tables
toast-shadow table.

It's no big deal, some additional checks of the va_toastrelid
beeing the same as the target relations toast relation should
do it.

Now since toast needs the row Oid allways, I think the idea
of making Oid's in user tables optional is dead.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com