spurious function execution in prepared statements.
От | Merlin Moncure |
---|---|
Тема | spurious function execution in prepared statements. |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3412A74DD@Herge.rcsinc.local обсуждение исходный текст |
Ответы |
Re: spurious function execution in prepared statements.
Re: [PERFORM] spurious function execution in prepared statements. Re: spurious function execution in prepared statements. |
Список | pgsql-hackers |
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: select f(t.c) from t where [boolean expr on t] limit 1; because of the limit phrase, obviously, at most one record is returned and f executes at most once regardless of the plan used (in practice, sometimes index, sometimes seq_scan. 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 seqscan, f executes for every row on t examined until the [expr] criteria is met. Is this a bug? If necessary I should be able to set up a reproducible example. The easy workaround is to not use prepared statements in these situations, but I need to be able to guarantee that f only executes once (even if that means exploring subqueries). Merlin
В списке pgsql-hackers по дате отправления: