Deferred trigger queue

Hi,
   looking at all the complications about dealing with segmented   files etc., I wonder if it's really worth the efford
to  add   file buffering to the trigger queue.
 
   The  memory  footprint left by modifying a row where triggers   have to be run is about 40 + 8 * num_triggers bytes.
So  for   one   PK/FP   relationship,  it  will  be  48  bytes  per  FK   inserted/updated or 48 bytes per PK
updated/deleted. If  one   PK  table  has  multiple references to it, this will only add   another 8 bytes to the
footprint. Same  if  one  table  has   multiple foreign keys defined.
 
   The  question now is, who ever attempts to act on millions of   rows in one transaction, if referential integrity
constraints  are set up?
 
   Of  course,  if  someone  updates  millions  of rows in an RI   scenario during one  transaction,  it  could  blow
away the   backend. But I'd prefer to leave this as a well known problem   for 7.1 and better start on creating a good
regression test   and some documentation for it.
 
   Thomas, where should the documentation for FOREIGN KEY go?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #