Re: Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

It's not that JDBC is slower, it is the plans that are being generated are
slower. I can't imagine why that would even happen.

JDBC doesn't really change the incoming SQL

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

On 11 January 2016 at 08:29, Christian Bjørnbak <cbj(at)touristonline(dot)dk>
wrote:

> @Vladimir but if 1202+ has become smarter than 1102 and reuse prepared
> statements more often how come Thomas experience the 1207 to be magnitudes
> slower?
>
> Shouldn't it be the other way around?
>
>
>
> Med venlig hilsen / Kind regards,
>
> Christian Bjørnbak
>
> Chefudvikler / Lead Developer
> TouristOnline A/S
> Islands Brygge 43
> 2300 København S
> Denmark
> TLF: +45 32888230
> Dir. TLF: +45 32888235
>
> 2016-01-11 14:05 GMT+01:00 Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
> :
>
>> The difference is as follows: 1202 can cache across statement.close()
>> calls. 1201 can't do that.
>>
>> In other words, to use server-prepared statements in previous
>> versions, you had to reuse the *same* PreparedStatement *object* again
>> and again. As soon as you issue .close() you lose your shiny
>> server-prepared statement.
>>
>> Typical applications are written in a form of
>> PreparedStatement ps = con.prepareStatement(sql);
>> ps.excuteQuery();
>> ps.close();
>>
>> In other words, almost always developers just recreate
>> PreparedStatement and close it.
>> The improvement of 1202 was to identify such patterns and use
>> server-prepared statement in such cases as well.
>> Vladimir
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>
>