Re: interesting trigger behaviour in 8.3
От | Ivan Zolotukhin |
---|---|
Тема | Re: interesting trigger behaviour in 8.3 |
Дата | |
Msg-id | 751e56400807310417u264f4000h357d4880a3a3279a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: interesting trigger behaviour in 8.3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Tue, Jul 29, 2008 at 7:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Ivan Zolotukhin" <ivan.zolotukhin@gmail.com> writes: >> In pseudo code it looks like the following. There are 2 tables, empty >> abstract_table with 3 columns (id, col1, col2) and many tables (e.g. >> inherited_table1_with_data) that inherit abstract_table. >> Constraint_exclusion is set up on id column and works perfectly. So >> we've got update like this > >> UPDATE abstract_table SET col1 = 1, col2 = 2 WHERE id = 12345; > > I bet it does not *really* look like that, but has a parameterized > WHERE clause. As per the fine manual: > > Constraint exclusion only works when the query's WHERE clause > contains constants. A parameterized query will not be optimized, > since the planner cannot know which partitions the parameter value > might select at run time. For the same reason, "stable" functions > such as CURRENT_DATE must be avoided. Thank you Tom for your remark. I just missed this point from the docs. -- Regards, Ivan
В списке pgsql-general по дате отправления: