From: | Joshua Engel <postgres(at)purgo(dot)net> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | getFastLong gets longs slowly |
Date: | 2014-05-28 21:54:16 |
Message-ID: | CADs656r451+12EsC0ZeXzt08D9kfw7QCW=eLKuuA0vZNB8HFvQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
I tracked down a performance problem to the JDBC driver's getFastLong
function.
For very large long values (in particular, Long.MAX_VALUE and MIN_VALUE), a
special case in getFastLong throws an exception (FAST_NUMBER_FAILED)
because it's 19 digits rather than 18. It's then caught and reprocessed
using the regular long processing code (mostly, deferring to Long.getLong).
In the JVMs I'm using (JDK 6 and 7), the delay introduced by that exception
is substantial. It's not large on a per-instance basis but I'm sorting
through a great many records, many of which are MAX_VALUE. Several
different performance measurement tools all put the blame right there.
I compiled the code myself with larger values for that cutoff, and get a
huge performance increase.
So... is there a way I can check that change in?
And incidentally, while I'm at it... is there any reason it's storing my
long values as binary coded decimal? Can I get it to stop doing that? The
whole point of using a long rather than a string value was presumably to
have it work faster.
Thanks,
Joshua Engel
From | Date | Subject | |
---|---|---|---|
Next Message | Mikko Tiihonen | 2014-05-29 08:46:12 | Re: getFastLong gets longs slowly |
Previous Message | Christophe Canovas | 2014-05-26 10:23:59 | bad performances since 9.1 version |