Re: Why is the number of dead tuples causing the performance of deferred triggers to degrading so rapidly (exponentionally)?

Frank,

> It seems in this case the time needed for a single deferred trigger somehow
> depends on the number of dead tuples in the table, because a vacuum of the
> table will 'reset' the query-times. However, even if I wanted to, vacuum is
> not allowed from within a function.
>
> What is happening here? And more importantly, what can I do to prevent
> this?

I'm not clear on all of the work you're doing in the trigger.  However, it
seems obvious that you're deleting and/or updating a large number of rows.
The escalating execution times would be consistent with that.

> NB. My real-world application 'collects' id's in need for deferred work,
> but this work is both costly and only needed once per base record. So I use
> an 'update' table whose content I join with the actual tables in order to
> do the work for _all_ the base records involved upon the first execution of
> the deferred trigger. At the end of the trigger, this 'update' table is
> emptied so any additional deferred triggers on the same table will hardly
> lose any time. Or at least, that was the intention....

I think you're doing a lot more than is wise to do in triggers.   Deferrable
triggers aren't really intended for running long procedures with the creation
of types and temporary tables (your post got a bit garbled, so pardon me if
I'm misreading it).   I'd suggest reconsidering your approach to this
application problem.

At the very least, increase max_fsm_relations to some high value, which may
help (or not).

-Josh

--
__Aglio Database Solutions_______________
Josh Berkus               Consultant
josh@agliodbs.com     www.agliodbs.com
Ph: 415-752-2500    Fax: 415-752-2387
2166 Hayes Suite 200    San Francisco, CA