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
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 |