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
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 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 i
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, CI.OLDVALUE, CI.OLDSTRING, CI.NEWVALUE,
CI.NEWSTRING
from PUBLIC.
