From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Barry Lind <barry(at)xythos(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Interesting results using new prepared statements |
Date: | 2002-09-12 20:12:35 |
Message-ID: | 9528.1031861555@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Barry Lind <barry(at)xythos(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2002-09-12 20:58:11 | Looking for more "big name" places that use PostgreSQL |
Previous Message | Justin Clift | 2002-09-12 19:35:49 | Looking for more "big name" places that use PostgreSQL |