"Eric B. Ridge" <[EMAIL PROTECTED]> writes:
> On Mar 25, 2006, at 12:24 AM, Tom Lane wrote:
>> This is the sort of detail that you really should not omit.
> I'm now curious if complex rules can influence the planner in
> negative ways.
It's possible. I'm not certain that that is really what yo
On Mar 25, 2006, at 12:24 AM, Tom Lane wrote:
This is the sort of detail that you really should not omit.
Yeah, it didn't even occur to me until I ran the "explain execute foo
(42)" thing you suggested. We've been using these update rules for
so long that I just think of the views as regul
"Eric B. Ridge" <[EMAIL PROTECTED]> writes:
> I should have mentioned that while the UPDATE statement in the
> trigger function really is as simple as the above, "some_other_table"
> is actually a view with the requisite ON UPDATE DO INSTEAD rule:
This is the sort of detail that you really shoul
On Mar 24, 2006, at 11:39 PM, Tom Lane wrote:
The issue is probably that the planner is seeing a parameterized
query. Try this:
prepare foo(int8) as update some_other_table SET field = 'value'
WHERE id = $1;
explain execute foo(42);
I should have mentioned that while the UPDATE statement
"Eric B. Ridge" <[EMAIL PROTECTED]> writes:
> When is the UPDATE statement inside foo() planned? When the trigger
> is first created, or when it's first used per backend, or every time
> it's used per backend?
First use per backend, ignoring corner cases such as replacing the
function definit
I've found a few performance issues with an internal database
application and I'm sure it's related to my misunderstanding of how
and when queries are planned when used in a plpgsql function. This
is against Postgres 7.4.
For example, suppose this function is defined as a per-statement
u
