From: Rainer Pruy <Rainer.Pruy@Acrys.COM>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Query slowing down significantly??
Date: Mon, 01 Mar 2010 19:49:07 +0100
Message-ID: <4B8C0C23.9000107@acrys.com> (raw)
In-Reply-To: <20628.1267467300@sss.pgh.pa.us>
References: <4B8BB815.4060104@acrys.com>
<17910.1267460132@sss.pgh.pa.us>
<4B8BFDEF.1080006@acrys.com>
<20628.1267467300@sss.pgh.pa.us>
I'm already at it
It is a Java app, using jdbc, but through a proprietary persistence framework.
I'm just busy evaluating the effects on the app of prohibiting prepared statements via jdbc.
If this is not worthwhile, I'm bound to some expensive reorganizations, sigh.
Nevertheless,
thanks for your help
in reminding me about obvious use of prepared statements.
Rainer
PS:
I've just read the thread on "Avoiding bad prepared-statement plans".
Very interesting. Will track this...
Am 01.03.2010 19:15, wrote Tom Lane:
> Rainer Pruy <Rainer.Pruy@Acrys.COM> writes:
>> The prepared statement gives:
>> ...
>> And that is quite a bad plan given the current distribution of values.
>
> Yeah. The planner really needs to know the actual parameter values in
> order to pick the best plan for this case.
>
> One thing that you might be able to do to avoid giving up on prepared
> statements entirely is to use an "unnamed" rather than named prepared
> statement here. That will lead to the query plan being prepared only
> when the parameter values are made available, rather than in advance.
> It'd depend on what client library you're using whether this is a simple
> change or not.
>
> regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: Rainer.Pruy@Acrys.COM, tgl@sss.pgh.pa.us
Subject: Re: Query slowing down significantly??
In-Reply-To: <4B8C0C23.9000107@acrys.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox