Message-ID: <4B8C0C23.9000107@acrys.com>
Date: Mon, 01 Mar 2010 19:49:07 +0100
From: Rainer Pruy <Rainer.Pruy@Acrys.COM>
Organization: Acrys Consult GmbH & Co. KG
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de;
	rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Lightning/1.0b1
	Thunderbird/3.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Query slowing down significantly??
References: <4B8BB815.4060104@acrys.com> <17910.1267460132@sss.pgh.pa.us>
	<4B8BFDEF.1080006@acrys.com> <20628.1267467300@sss.pgh.pa.us>
In-Reply-To: <20628.1267467300@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

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