bject: Re: text fields and performance for ETL
On Fri, 2021-11-05 at 11:27 -0400, Bruce Momjian wrote:
> On Fri, Nov 5, 2021 at 07:32:12AM -0700, David G. Johnston wrote:
> > On Friday, November 5, 2021, Bruce Momjian wrote:
> >
> >
> > >
> > &
On Thu, 2021-11-11 at 09:44 +, Grega Jesih wrote:
> with this approach, why don't you eliminate char and varchar then ?
> Thanks for thinking over.
Two reasons:
- the SQL standard requires these types
- sometimes you want to enforce a length limit, and a "type modifier" like
varchar(30) is
On Fri, 2021-11-05 at 11:27 -0400, Bruce Momjian wrote:
> On Fri, Nov 5, 2021 at 07:32:12AM -0700, David G. Johnston wrote:
> > On Friday, November 5, 2021, Bruce Momjian wrote:
> >
> >
> > >
> > > Perhaps, right before the tip you quoted, something like that:
> > >
> > > If y
On Fri, Nov 5, 2021 at 07:32:12AM -0700, David G. Johnston wrote:
> On Friday, November 5, 2021, Bruce Momjian wrote:
>
>
> >
> > Perhaps, right before the tip you quoted, something like that:
> >
> > If your use case requires a length limit on character data, or
> complia
On Friday, November 5, 2021, Bruce Momjian wrote:
>
> >
> > 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
On Fri, Nov 5, 2021 at 03:15:35PM +0100, Laurenz Albe wrote:
> On Fri, 2021-11-05 at 09:51 +, 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,
On Fri, 2021-11-05 at 09:51 +, 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
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
Sent: Thursday, November 4, 2021 2:51 PM
To: Grega Jesih
Cc: Tom Lane ; Pg Docs
Subject: Re: text fiel
On Thursday, November 4, 2021, Grega Jesih 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 "withi
h-method-when-dealing-with-source-lob-columns
If this contribution from stackexchange isn't enough, let me know.
BR
Grega
From: David G. Johnston
Sent: Wednesday, November 3, 2021 7:40 PM
To: Grega Jesih
Cc: Tom Lane ; grega.je...@gmail.com; Pg Docs
Subject: Re: text fields and perfo
Grega Jesih writes:
> It matters a lot. It means time saving. Plenty of time. So we're talking
> performance. Not postgres performance, interface performance.
One more time: our docs are here to explain Postgres performance.
It is very easy to show that char/varchar are strictly worse than
text
On Wed, Nov 3, 2021 at 11:09 AM Grega Jesih
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 demonstrat
: David G. Johnston; grega.je...@gmail.com; Pg Docs
Zadeva: Re: text fields and performance for ETL
Grega Jesih writes:
>> The goal in our docs is to point out that using an arbitrary length
>> specification is not required in PostgreSQL.
> Well perhaps yours. But there are pro-
Grega Jesih writes:
>> The goal in our docs is to point out that using an arbitrary length
>> specification is not required in PostgreSQL.
> Well perhaps yours. But there are pro-tools (I refer to SSIS in this context)
> that provide a very fast dataflow in case there is a known record size.
T
a biiig difference.
Best regards
Grega
PS
I work in actual-it.si and gmail.com mail is fwded to me. So I took a shorcut
here..
From: David G. Johnston
Sent: Wednesday, November 3, 2021 3:38 PM
To: grega.je...@gmail.com; Pg Docs
Subject: Re: text fields and performance for ETL
On Wed
On Wed, Nov 3, 2021 at 8:35 AM Grega Jesih wrote:
> Dear David,
>
> > The goal in our docs is to point out that using an arbitrary length
> specification is not required in PostgreSQL.
>
> Then it should say so. Because unexperienced reader then uses this limited
> focus and generalizes.
>
It do
On Wed, Nov 3, 2021 at 6:55 AM PG Doc comments form
wrote:
> But performance in ETL processes related to such data type is decreased
> dramatically, because any process that takes this kind of data needs to
> calculate its size on a row level and cannot take bigger chunks of data
> based on max s
On Wed, Nov 3, 2021 at 01:29:19PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/datatype-character.html
> Description:
>
> Text field is a field that is intended for very big texts.
> Perfor
18 matches
Mail list logo
