Re: Trouble with plan statistics for behaviour for query.

Thanks for all your help so far. I have been away for a couple of days so my apologies for not replying earlier.

We are using a third party library to run our SQL via JDBC (not one of the common ones like Hibernate etc), but I have
been able to dig out the exact statements run in the scenario we are experiencing.

We always run a prepare and then execute a query as follows, we never reuse the prepared statement:

_ps = _connection.prepareStatement(sql, resultSetType, resultSetConcurrency);

// The values here are:
// sql = SELECT CG.ID, CG.issueid, CG.AUTHOR, CG.CREATED, CI.ID, CI.groupid, CI.FIELDTYPE, CI.FIELD, CI.OLDVALUE,
CI.OLDSTRING, CI.NEWVALUE, CI.NEWSTRING
// FROM public.changegroup CG INNER JOIN public.changeitem CI ON CG.ID = CI.groupid
// WHERE CG.issueid=? ORDER BY CG.CREATED ASC, CI.ID ASC
// resultSetType = ResultSet.TYPE_FORWARD_ONLY
// resultSetConcurrency = ResultSet.CONCUR_READ_ONLY

_ps.setLong(1, field);

_rs = _ps.executeQuery();

On 02/06/12 01:38, Maciek Sakrejda wrote:
>> If I am correct, JDBC uses named portal only on the 5th time you use
>> PreparedStatement (configurable). Before it uses unnamed thing that should
>> work as if you did embed the value.
> If this is due to the difference in parameter type information, this
> doesn't have anything to do with named portals.
>
> My guess is that the driver has one idea about parameter types (based
> on either the specific setTypeFoo call or the Java type of the
> parameter passed to setObject), and the server another (based on the
> type information of the CHANGEGROUP.ISSUEID column). Actually, I'm
> rather surprised to see 'real' there: if you're using setObject with a
> Long, I would imagine that turns into a bigint (which I believe the
> server knows how to coerce to numeric). Can you show us your JDBC
> code?