Re: Deferred trigger queue

Jan, I have added to the TODO list:
* Add deferred trigger queue file? (Jan)

Do you want this in there?

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


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026