Condsidering all the processing required by the query, the conversion
and number of bytes sent over the nework really don't affect
performance.
---------------------------------------------------------------------------
Joris van Zwieten wrote:
> Hi everyone,
>
>
> I've been using postgres for several projects and I must confess I really
> like it so far. :-) I hope someone on this list could help me out.
>
> Suppose I have a table defined with:
> CREATE TABLE foo(bar double precision[]);
>
> My initial guess was that, as postgres supports arrays, there would
> probably also be some support for this in libpq (which I'm using via
> libpqxx by the way).
>
> However, from what I've been able to find, it seems that if I use the text
> format for parameters / results, I would have to:
>
> 1. [SEND] Convert the double array on the C(++) side to a '{}' delimited
> string representation.
> 2. [RECV] Convert something like '{3.124, 4.5234, 123.123}' to a C(++)
> array of doubles myself.
>
> I hope I overlooked something and there is some support for sending /
> receiving (parsing) arrays in libpq?? That would be a big help.
>
> Still, sending double in ASCII does not seem that efficient. It's not a
> trivial conversion and it takes more bytes than sending it as binary.
> However, it seems that using the binary format, I would have to:
>
> 1. [SEND] Convert to network byte order
> Send the array in the format arrayfuncs.c::array_recv() expects,
> i.e. including the right header (and a length per element as
> well).
> 2. [RECV] Parse the header, and convert from byte order
>
> Am I missing something here? Or is this just the way it is? (Which is also
> fine, then at least I know what I'm up against... ;-)
>
> Thanks,
>
> Joris van Zwieten
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +