Re: [GENERAL] COPY: row is too big - Mailing list pgsql-general

From Adrian Klaver
Subject Re: [GENERAL] COPY: row is too big
Date
Msg-id 591360d9-00db-4e83-0feb-0b22109414f1@aklaver.com
Whole thread Raw
In response to Re: [GENERAL] COPY: row is too big  (Steve Crawford <scrawford@pinpointresearch.com>)
Responses Re: [GENERAL] COPY: row is too big  (vod vos <vodvos@zoho.com>)
List pgsql-general
On 01/04/2017 08:32 AM, Steve Crawford wrote:
> ...
>
>         Numeric is expensive type - try to use float instead, maybe double.
>
>
>     If I am following the OP correctly the table itself has all the
>     columns declared as varchar. The data in the CSV file is a mix of
>     text, date and numeric, presumably cast to text on entry into the table.
>
>
> But a CSV *is* purely text - no casting to text is needed. Conversion is
> only needed when the strings in the CSV are text representations of
> *non*-text data.

Yeah, muddled thinking.

>
> I'm guessing that the OP is using all text fields to deal with possibly
> flawed input data and then validating and migrating the data in
> subsequent steps. In that case, an ETL solution may be a better
> approach. Many options, both open- closed- and hybrid-source exist.
>
> Cheers,
> Steve


--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Steve Crawford
Date:
Subject: Re: [GENERAL] COPY: row is too big
Next
From: Tom DalPozzo
Date:
Subject: [GENERAL] replication slot to be used in the future