From: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
---|---|
To: | "Jeff Lynn" <jmlynn(at)rogers(dot)com> |
Cc: | "Andrew McNamara" <andrewm(at)object-craft(dot)com(dot)au>, pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: PQgetvalue failed to return column value for non-text data in binary format |
Date: | 2007-05-22 06:10:25 |
Message-ID: | 10260.125.24.233.43.1179814225.squirrel@webmail.xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
On Tue, May 22, 2007 04:46, Jeff Lynn wrote:
> This is interesting position to be taken by PostgreSQL. For simple
> query, particularly with regards to reporting, one can go about using
> text for all column. But a lot of time, I deal with large dataset
> ingestions and extracts that tends to take many hours to perform. So I
> usually prefer binary form data for performance reason. To that end, I
> found there is a significant different in the time it takes to ingest or
> extract data from one database to another database of totally different
> vendor. Most of our company's works are done in Java nowadays, but for
> large data ingestions/extract/conversion, a C program out performs Java
> program fair and square, no debate there (based on actual run-time
> data). For clarification, we deal with various business partners that
> we have to import/export large amount of data between heterogeneous
> databases that the wonderful technology of database replication does not
> apply for our use.
For that kind of thing, may I suggest you try using the COPY API? That
may buy you more speed than transferring data in binary form
would—particularly for insertions.
Jeroen
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Lynn | 2007-05-22 18:17:53 | Re: PQgetvalue failed to return column value for non-text data in binary format |
Previous Message | Andrew McNamara | 2007-05-21 23:39:56 | Re: PQgetvalue failed to return column value for non-text data in binary format |