| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Fuhr <mike(at)fuhr(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Plan chosen for PQexecParams |
| Date: | 2005-11-20 22:21:03 |
| Message-ID: | 23524.1132525263@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> I've noticed that if a client uses PQexecParams, the query plan
> appears to be identical to the plan chosen for PQprepare/PQexecPrepared,
> which might not be as optimal as a plan chosen for PQexec. I can
> understand the PQprepare case since the planner doesn't know what
> parameters will actually be used, but with PQexecParams shouldn't
> the planner have all the information it needs to choose a plan based
> on specific parameters? Is PQexecParams just shorthand for a prepare
> followed by an execute?
Yes, but it uses the unnamed statement, so in recent server versions you
should get a postponed plan that uses the Bind parameter values. What
test case are you looking at exactly?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2005-11-21 00:11:48 | plpython and bytea |
| Previous Message | Martijn van Oosterhout | 2005-11-20 21:41:42 | Re: Returning multiple result sets |