Best practices for (plpgsql ?) trigger optimization?

From: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Best practices for (plpgsql ?) trigger optimization?
Date: 2005-04-01 16:19:55
Message-ID: 1112372395l.5596l.2l@mofo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

Are there any best practices for optimizing triggers,
and, I suppose, stored procedures as well? I am now
starting on optimization and before I begin am
hoping to avoid re-inventing the wheel.

The problems I see are:

1) There is no way to profile where a problem lies.
When there are large and/or nested triggers there
could be a 'bad query' anywhere. Finding it seems
difficult.

2) The NEW and OLD tables used by triggers don't exist
outside of a trigger environment, yet EXPLAIN returns
statement results -- and which is basically illegal inside
triggers.

The solutions I see are to use:

SET client_min_messages DEBUG1;
SET debug_print_plan TRUE;

and maybe
SET log_executer_stats TRUE;

Is this the best approach? Any tricks for sorting through the
resultant output?

It'd be nice to have some hints about this in the User's Guide.

Thanks.

Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Fuhr 2005-04-01 16:27:35 Re: : Postgres order by into a RECORD, not ordering
Previous Message Scott Marlowe 2005-04-01 15:56:45 Re: Temporary Tables