Re: [GENERAL] COPY: row is too big

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: [GENERAL] COPY: row is too big
Дата
Msg-id 591360d9-00db-4e83-0feb-0b22109414f1@aklaver.com
обсуждение исходный текст
Ответ на Re: [GENERAL] COPY: row is too big  (Steve Crawford <scrawford@pinpointresearch.com>)
Ответы Re: [GENERAL] COPY: row is too big
Список 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 по дате отправления:

Предыдущее
От: Steve Crawford
Дата:
Сообщение: Re: [GENERAL] COPY: row is too big
Следующее
От: Tom DalPozzo
Дата:
Сообщение: [GENERAL] replication slot to be used in the future