pg.ddx.io pgsql-performance@postgresql.org mailing list archive help / color / mirror / Atom feed From: Rural Hunter <ruralhunter@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Geoserver-PostGIS performance problems
Date: Thu, 26 Jul 2012 10:13:48 +0800
Message-ID: <5010A7DC.5000202@gmail.com> (raw )
In-Reply-To: <CAM9BftxxTMdqrL_9wux8okFBuNdBu21EDV7H7f_Rv+zgueHZ2Q@mail.gmail.com >
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 >
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
>
view thread (13+ messages) latest in thread
Message-ID: <5010A7DC.5000202@gmail.com>
Permalink: ../5010A7DC.5000202@gmail.com/
Also on: postgresql.org/message-id/5010A7DC.5000202@gmail.com
copy link · copy postgr.es
reply 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: ruralhunter@gmail.com
Subject: Re: Geoserver-PostGIS performance problems
In-Reply-To: <5010A7DC.5000202@gmail.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