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