Re: text fields and performance for ETL

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Grega Jesih <Grega(dot)Jesih(at)actual-it(dot)si>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: text fields and performance for ETL
Date: 2021-11-05 14:15:35
Message-ID: b288134ae2290d5abc2a2d516a8d58892a656f30.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Fri, 2021-11-05 at 09:51 +0000, Grega Jesih wrote:
> Suggested current text addendum:
>
> But, if you consider doing ETL from Postgres database to some outer target
> environment and you seek performance in such interfaces, follow the logic
> of limited size (varchar or char) data types in your database model.
> Because if you make a dataflow of known size types, interface code can take
> a big block of data while for text fields you need to check each record.

I am opposed to that.

It is not our business to discuss the limitations of a certain third-party software product.
If that were something wide-spread, perhaps. But I myself have never seen a problem
with "text", as long as the actual size of the data is moderate.
 
> Optional additional remark:
>
> Another good aspect of known data sizes is easier understanding of field
> content and implicit data (length) control.

Something like that makes more sense to me.

Perhaps, right before the tip you quoted, something like that:

If your use case requires a length limit on character data, or compliance
with the SQL standard is important, use "character varying".
Otherwise, you are usually better off with "text".

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2021-11-05 14:17:12 Re: text fields and performance for ETL
Previous Message Grega Jesih 2021-11-05 09:51:08 RE: text fields and performance for ETL