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 по дате отправления: