Best practices for (plpgsql ?) trigger optimization?
| От | Karl O. Pinc |
|---|---|
| Тема | Best practices for (plpgsql ?) trigger optimization? |
| Дата | |
| Msg-id | 1112372395l.5596l.2l@mofo обсуждение исходный текст |
| Ответы |
Re: Best practices for (plpgsql ?) trigger optimization?
|
| Список | 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@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
В списке pgsql-general по дате отправления: