Hi Josh,

> > It seems in this case the time needed for a single deferred trigger
> > somehow depends on the number of dead tuples in the table

After further investigation I think I have a better grasp of what's going on.

The thing biting me here is indeed the 'delete from' on a table with a number 
of dead rows, possibly made worse in some cases where not everything can be 
handled in memory.

> I'm not clear on all of the work you're doing in the trigger.
> > NB. My real-world application 'collects' id's in need for deferred work
> I think you're doing a lot more than is wise to do in triggers.

I probably wasn't clear enough on this. I'm not creating types and/or 
temporary tables or anything of that kind.

The ratio is probably explained better by this example:

- the database has knowledge on 'parts' and 'sets', the sets have a few fields 
whose content depend on the parts, but the proper value for these fields can 
only be determined by looking at all the parts of the particular set together 
(i.e. it's not a plain 'part-count' that one could update by a trigger on the 

- during a transaction, a number of things will happen to various parts of 
various sets, so I have after triggers on the parts that will insert the ids 
of the sets that need an update into a set_update holding table; in turn, 
this set_update table has a deferred trigger

- upon execution of the deferred triggers, I now know that all the work on the 
parts is finished, so the deferred trigger initiates an update for the sets 
whose ids are in the update table and it will delete these ids afterwards

Now, because multiple updates to parts of the same set will result in multiple 
inserts in the update table, I want to avoid doing the set-update more that 

Obviously, it would be better to be able to 'cancel' the rest of the calls to 
the deferred trigger after it has been executed for the first time, but that 
doesn't seem possible.

Even better would be to use a 'for each statement' trigger on the set_update 
holding table instead, but it is not possible to create a deferred 'for each 
statement' trigger..... ;(

So, I seem to be a bit between a rock and a hard place here, I must use 
deferred triggers in order to avoid a costly set update on each part update, 
but in such a deferred trigger I cannot avoid doing the update multiple 
times....(due to the growing cost of a 'delete from' in the trigger)

Mmm, it seems that by hacking pg_trigger I am able to create a for each 
statement trigger that is 'deferrable initially deferred'.

This probably solves my problem, I will ask on 'general' whether this has any 
unforseen side effects and whether or not a 'regular' deferrable for each 
statement trigger is incorporated in v8.0.

Thanks for you reply!



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to