"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> now, if ps ends up using a index scan on t, everything is ok. However,
> if ps does a seqscan, f executes for every row on t examined until the
> [expr] criteria is met. Is this a bug?
Works for me.
regression=# create function f(int) returns int a
> Here's another workaround that may let you use a prepared statement:
>
> prepare ps(...) as
> select f(c) from (select c from t where [expr] limit 1) as t1
>
> -Mike
I was just exploring that. In fact, the problem is not limited to
prepared statements...it's just that they are more likely to
On Thu, Sep 30, 2004 at 09:45:51AM -0400, Merlin Moncure wrote:
> Now, if the same query is executed as a prepared statement,
> prepare ps(...) as select f(t.c) from t where [expr] limit 1;
> execute ps;
>
> now, if ps ends up using a index scan on t, everything is ok. However,
> if ps does a seq
OK, I have a situation that might be a performance problem, a bug, or an
unavoidable consequence of using prepared statements. The short version
is that I am getting function executions for rows not returned in a
result set when they are in a prepared statement.
In other words, I have a query:
se
