Re: Geoserver-PostGIS performance problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux