Message-ID: <5010A7DC.5000202@gmail.com>
Date: Thu, 26 Jul 2012 10:13:48 +0800
From: Rural Hunter <ruralhunter@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Geoserver-PostGIS performance problems
References: <500E690D020000DB000A78CC@pta-emo.csir.co.za>
	<4B95BC7335A13A42AD0D23462F91AE6F6163F14852@echo.geometryit.com>
	<500E7478020000DB000A78E9@pta-emo.csir.co.za>
	<CAOtHd0Ai_SMfU7G2k9j+bXqrKJYMQQchoRqU_qiFGyvmv7m8QA@mail.gmail.com>
	<CAHyXU0wS9V_k70gEMA7qGCL3nOvZE58TSTuz0W6hXSFEgBdD6w@mail.gmail.com>
	<CAM9BftyxfNN0ouWo7hQ5yFK=hN1xBGs+ri95R4BWk9wboU3vYA@mail.gmail.com>
	<CAHyXU0wMoin6YSdFYCrRVMQc+DK8tYn76cRaSEnzx_=maAdHAA@mail.gmail.com>
	<CAM9BftxxTMdqrL_9wux8okFBuNdBu21EDV7H7f_Rv+zgueHZ2Q@mail.gmail.com>
In-Reply-To: 
 <CAM9BftxxTMdqrL_9wux8okFBuNdBu21EDV7H7f_Rv+zgueHZ2Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Why not just use simple Statement instead of PreparedStatement and 
construct the SQL with concated string or StringBuilder? like this:
int col1=xxx;
String col2="xxxx";
String sql="select * from table where col1="+col+" and col2='"+col2+"'";

于 2012/7/26 3:59, Vinicius Abrahao 写道:
> On Wed, Jul 25, 2012 at 4:26 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao <vinnix.bsd@gmail.com> wrote:
>>> On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>>>> Note that it seems the preparing/planning interaction was not the
>>>>> poster's actual problem, but it may have been yours. As Tom Lane notes
>>>>> in that thread, this should get better in 9.2.
>>>> jdbc should get some blame too -- it's really aggressive about
>>>> preparing queries.
>>>>
>>> indeed!
>>> Is there any reason for that?
>> IMNSHO it's an oversight in the core JDBC design dating back to the
>> beginning: you have two basic choices for executing SQL.  The
>> unparameterized Statement or the parameterized PreparedStatement.
>> There should have been a 'ParamaterizedStatement' that gave the
>> expectation of paramaterization without setting up and permanent
>> server side structures to handle the query; libpq makes this
>> distinction and it works very well.  Of course, there are various ways
>> to work around this but the point stands.
>>
> That is true, I was observing the same, days ago:
>
> Running queries and statments in jdbc:
> https://github.com/vinnix/JavaLab/blob/master/Scrollable.java
>
> And running queries with libpq:
> https://github.com/vinnix/testLibPQ/blob/master/testlibpq.c
>
> Is this possible to change something (I really don't know what or
> where) in the jdbc driver
> to get more direct aproach? (if that's make any sense to you guys...)
>
> Best regards,
>
> vinnix
>