From: Grega Jesih <Grega.Jesih@actual-it.si>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Docs <pgsql-docs@lists.postgresql.org>
Subject: RE: text fields and performance for ETL
Date: Fri, 5 Nov 2021 09:51:08 +0000
Message-ID: <516dc58b80fa418091f5262879019213@actual-it.si> (raw)
In-Reply-To: <CAKFQuwbX37AwNcKHMeaOq+LS_nhw_6sHwaUK1+UsQ8Nuo7bcfg@mail.gmail.com>
References: <163594615980.678.1904941309603792278@wrigleys.postgresql.org>
<CAKFQuwa_02fEtL8zJMt7MR=xvrp-De1pQtHFtg7fSHhSm1ajnA@mail.gmail.com>
<686716cb5c4242c28e5967d9b6fcfc75@actual-it.si>
<137264.1635961048@sss.pgh.pa.us>
<c57e7a702932465ca9962d4f5d332c3a@actual-it.si>
<CAKFQuwYFfESp=xUpktYBbW8TxO8k=+uWN8F2G5Ehis2cpYuDnw@mail.gmail.com>
<70cf9fe110c246afb4eab054caab0c04@actual-it.si>
<CAKFQuwbX37AwNcKHMeaOq+LS_nhw_6sHwaUK1+UsQ8Nuo7bcfg@mail.gmail.com>
Hi David.
> We’re entitled to a bit of self-centeredness here, especially when the broader world is so varied
One can tell ;-)
Current text:
[cid:image001.png@01D7D233.09B9B710]
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.
Optional additional remark:
Another good aspect of known data sizes is easier understanding of field content and implicit data (length) control.
Best regards
Grega
From: David G. Johnston <david.g.johnston@gmail.com>
Sent: Thursday, November 4, 2021 2:51 PM
To: Grega Jesih <Grega.Jesih@actual-it.si>
Cc: Tom Lane <tgl@sss.pgh.pa.us>; Pg Docs <pgsql-docs@lists.postgresql.org>
Subject: Re: text fields and performance for ETL
On Thursday, November 4, 2021, Grega Jesih <Grega.Jesih@actual-it.si<mailto:Grega.Jesih@actual-it.si>> wrote:
So why would it then be published ? Because inexperienced programmers take your statement that "it's the same performance" from a wrong perspective, so it would be fair to note, that the remark "it's the same performance" is meant "within any operation inside Postgres database". In the moment we want to take this data elsewhere,
the problematic lack of model design comes out.
If you wish to supply an actual patch for consideration I’d review it. Absent that the documentation serves the vast majority of readers well as-is. We’re entitled to a bit of self-centeredness here, especially when the broader world is so varied.
David J.
NOTICE - NOT TO BE REMOVED.
This e-mail and any attachments are confidential and may contain legally privileged information and/or copyright material of Actual I.T. or third parties. If you are not an authorised recipient of this e-mail, please contact Actual I.T. immediately by return email or by telephone or facsimile on the above numbers.
You should not read, print, re-transmit, store or act in reliance on this email or any attachments and you should destroy all copies of them.
Attachments:
[image/png] image001.png (39.0K, ../516dc58b80fa418091f5262879019213@actual-it.si/3-image001.png)
download | view image
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: Grega.Jesih@actual-it.si, david.g.johnston@gmail.com, tgl@sss.pgh.pa.us, pgsql-docs@lists.postgresql.org
Subject: RE: text fields and performance for ETL
In-Reply-To: <516dc58b80fa418091f5262879019213@actual-it.si>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox