Re: OID wraparound: summary and proposal

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