Re: text fields and performance for ETL

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Grega Jesih <Grega(dot)Jesih(at)actual-it(dot)si>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "grega(dot)jesih(at)gmail(dot)com" <grega(dot)jesih(at)gmail(dot)com>, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: text fields and performance for ETL
Date: 2021-11-03 18:40:18
Message-ID: CAKFQuwYFfESp=xUpktYBbW8TxO8k=+uWN8F2G5Ehis2cpYuDnw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Wed, Nov 3, 2021 at 11:09 AM Grega Jesih <Grega(dot)Jesih(at)actual-it(dot)si>
wrote:

> The new architectures include more and more data exchange among databases.
> Now when you deal with bigger data sizes that go from millions to
> billions, this fixed size vs of text - undefined size becomes very
> relevant.
>
Can you demonstrate, with actual numbers, using today's implementation, a
situation where defining a column as char(3) or varchar(3) instead of text
has a significant performance improvement? Without a concrete example to
examine I'm unable to be convinced to move away from the status quo.

You also need to convince me as to why constraints are an insufficient
feature. i.e., why is char(3) better than (check length(val) = 3)?

Even with all that I'd probably still not do anything beyond reviewing a
proposed patch (i.e, I wouldn't try to write one myself from scratch...I
don't have authority to commit regardless).

David J.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2021-11-03 18:50:47 Re: text fields and performance for ETL
Previous Message Grega Jesih 2021-11-03 18:09:28 Re: text fields and performance for ETL