Re: Geoserver-PostGIS performance problems

On Wed, Jul 25, 2012 at 2:59 PM, Vinicius Abrahao <vinnix(dot)bsd(at)gmail(dot)com> wrote:
> On Wed, Jul 25, 2012 at 4:26 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao <vinnix(dot)bsd(at)gmail(dot)com> wrote:
>>> On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure <mmoncure(at)gmail(dot)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...)

you can disable server-side preparing in the url or as library
setting. see here:
"jdbc:postgresql://localhost:5432/test?prepareThreshold=3";

unfortunately postgres jdbc is bugged and does not honor the above for
transaction control commands (begin, commit, etc). This patch
http://treehou.se/~omar/postgresql-jdbc-8.4-701-pgbouncer_txn.patch
will fix it, assuming it hasn't been fixed in recent postgres jdbc.

merlin