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(at)debis(dot)com (Jan Wieck) #