Re: Interesting results using new prepared statements
От | Tom Lane |
---|---|
Тема | Re: Interesting results using new prepared statements |
Дата | |
Msg-id | 9528.1031861555@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Interesting results using new prepared statements (Barry Lind <barry@xythos.com>) |
Ответы |
Re: Interesting results using new prepared statements
|
Список | pgsql-hackers |
Barry Lind <barry@xythos.com> writes: > ... I don't understand > why the timings for prepared statements would be less than for a regular > statement, and especially why using bind variables would be better than > without. I am concerned that prepared statements may be choosing a > different execution plan than non-prepared statements. That's entirely likely if you are using bind variables in the prepared statements, since the planner will not have access to the same constant values that it does in a plain SQL statement --- for example, "WHERE foo = $1" looks a lot different from "WHERE foo = 42" to the planner. In most cases I'd expect the planner to generate worse plans when given less info :-( ... but in your particular case it seems to be guessing slightly wrong. > But I am not > sure how to find out what the execution plan is for a prepared > statement, since EXPLAIN doesn't work for a prepared statement (i.e. > EXPLAIN EXECUTE <preparedStatementName>, doesn't work). Hmmm --- I can see the usefulness of that, but it looks like a new feature and hence verboten during beta. Maybe a TODO for 7.4? regards, tom lane
В списке pgsql-hackers по дате отправления: