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).
The (real) is just my fault in testing. I just copy/pasted from elsewhere and it is not what is coming f
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
> 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 port
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. So the solution is to
recreate PreparedStatement each time (so you will have no problems with
SQL injection). Note
On Thu, May 31, 2012 at 4:34 PM, Trevor Campbell wrote:
> Thanks Craig, that certainly leads down the right path.
>
> The following is all done in pgAdmin3:
>
> Using an actual value we I get the plan I expect
> explain analyze select CG.ID, CG.ISSUEID, CG.AUTHOR, CG.CREATED, CI.ID,
> CI.FIELDTYPE
Thanks Craig, that certainly leads down the right path.
The following is all done in pgAdmin3:
Using an actual value we I get the plan I expect
explain analyze select CG.ID, CG.ISSUEID, CG.AUTHOR, CG.CREATED, CI.ID, CI.FIELDTYPE, CI.FIELD, CI.OLDVALUE,
CI.OLDSTRING, CI.NEWVALUE, CI.NEWSTRING
On Thu, May 31, 2012 at 4:01 PM, Trevor Campbell wrote:
> On 01/06/12 08:55, Craig James wrote:
>
>
>
> On Thu, May 31, 2012 at 3:29 PM, Trevor Campbell
> wrote:
>
>> We are having trouble with a particular query being slow in a strange
>> manner.
>>
>> The query is a join over two large tables
On 01/06/12 08:55, Craig James wrote:
On Thu, May 31, 2012 at 3:29 PM, Trevor Campbell mailto:tcampb...@atlassian.com>> wrote:
We are having trouble with a particular query being slow in a strange
manner.
The query is a join over two large tables that are suitably indexed.
selec
On Thu, May 31, 2012 at 3:29 PM, Trevor Campbell wrote:
> We are having trouble with a particular query being slow in a strange
> manner.
>
> The query is a join over two large tables that are suitably indexed.
>
> select CG.ID, CG.ISSUEID, CG.AUTHOR, CG.CREATED, CI.ID, CI.FIELDTYPE,
> CI.FIELD,
