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) #