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

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