| From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
|---|---|
| To: | Royce Ausburn <royce(dot)ml(at)inomial(dot)com> |
| Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Prepared statements and suboptimal plans |
| Date: | 2011-09-20 23:39:03 |
| Message-ID: | 4E792417.5080205@ringerc.id.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 21/09/2011 7:27 AM, Royce Ausburn wrote:
> Hi all,
>
> It looks like I've been hit with this well known issue. I have
> a complicated query that is intended to run every few minutes, I'm
> using JDBC's Connection.prepareStatement() mostly for nice
> parameterisation, but postgres produces a suboptimal plan due to its
> lack of information when the statement is prepared.
>
> [snip]
>
> We've been worst hit by this query on an 8.3 site. Another site is
> running 8.4. Have there been improvements in this area recently?
> Upgrading to 9.0 might be viable for us.
Tom just mentioned that 9.1 will be able to re-plan parameterized
prepared statements, so this issue will go away. In the mean time you
can only really use the standard workaround of setting the prepare
theshold to 0 to disable server-side prepare, so you can continue to use
JDBC prepared statements and have the driver do the parameter
substitution for you.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Royce Ausburn | 2011-09-21 00:17:41 | Re: Prepared statements and suboptimal plans |
| Previous Message | Royce Ausburn | 2011-09-20 23:27:10 | Prepared statements and suboptimal plans |