On Tue, Nov 15, 2005 at 13:01:20 -0500,
Dave Cramer <[EMAIL PROTECTED]> wrote:
> I've talked to Ken Geis via email. He suggests that there is
> considerable overhead to be saved if we go to binary; especially in
> date, and timestamp fields
>
> One thing though if the date is 64 bit instead
Dave Cramer <[EMAIL PROTECTED]> writes:
> One thing though if the date is 64 bit instead of float, what does
> the binary output look like? Are they different ?
Quite, it's int64 instead of double ...
> If so this would seem to complicate things quite a bit.
Recent PG versions tell you which r
I've talked to Ken Geis via email. He suggests that there is
considerable overhead to be saved if we go to binary; especially in
date, and timestamp fields
One thing though if the date is 64 bit instead of float, what does
the binary output look like? Are they different ?
If so this would
Dave Cramer <[EMAIL PROTECTED]> writes:
> I was thinking that it may be necessary to issue a describe before
> the execute, but I'm thinking now that the driver can only handle
> specific types, so anything outside of what it knows about would be
> an error anyway.
> I gather it's not possib
Yeah,
I finally read it through and found it. There's some anecdotal
evidence of up to 2x performance, so I'm interested in how to
implement this in the jdbc driver. ( I'm a little skeptical about 2x)
I was thinking that it may be necessary to issue a describe before
the execute, but I'm
Dave Cramer <[EMAIL PROTECTED]> writes:
> Is there a way to force select * from foo to use binary values ?
In what context?
There is a provision for that in the V3 extended-query protocol.
regards, tom lane
---(end of broadcast)---
Is there a way to force select * from foo to use binary values ?
Dave
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
