Re: interesting trigger behaviour in 8.3
От | Tom Lane |
---|---|
Тема | Re: interesting trigger behaviour in 8.3 |
Дата | |
Msg-id | 11469.1217346721@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | interesting trigger behaviour in 8.3 ("Ivan Zolotukhin" <ivan.zolotukhin@gmail.com>) |
Ответы |
Re: interesting trigger behaviour in 8.3
|
Список | pgsql-general |
"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. regards, tom lane
В списке pgsql-general по дате отправления: