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.
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
aseparate 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
relationshould 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@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
