Re: Performance problem with timestamps in result sets

mikael-aronsson wrote:
> I do not think there is much more to do, the timestamp is just a 64 bit
> integer and you say an int takes 570ms/10920 calls and a timestamp takes
> 7130ms/8190 calls, this is about twice as much to get twice as much data.

This is wrong, and not just because your maths is wrong ;-)  Timestamps
are not "just a 64 bit integer" on the wire.

getTimestamp() is parsing a string representation of a timestamp
(multiple numeric fields, separators, etc) and massaging it into a
Timestamp in the right timezone (retriving the right Calendar and
converting to a milliseconds-per-epoch value from the individual
components and timezone info)

getInt() is parsing a string representation of a single number.

So I'd expect getTimestamp() to be noticably slower than getInt(), which
is what we see.

Going to binary-format results would help, as then you can transfer the
underlying value directly rather than having the backend format it all
then have the JDBC driver parse it, but noone has done that yet. One big
obstacle is that binary format results are somewhat all-or-nothing, it's
tricky to do it for only a single datatype. You'd also still have to do
some timezone conversion work, I think.

-O