Dear Tom and David,
>I'll just point out in passing, though, that "fixed record size" for text
>strings is an illusion as soon as you have to deal with non-ASCII data.
>So I'm skeptical that such optimizations are worth much anymore.
It doesn't matter is it ascii or not. A string is a string. An UTF-8 is also
one, just differently coded.
It matters a lot. It means time saving. Plenty of time. So we're talking
performance. Not postgres performance, interface performance.
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.
But what I am trying to achieve is that you describe a view local to database
itself and and broader view, integration.
There is also the inner aspect of a database model where for a currency of true
size 3 you choose char(3) instead of text.
You prevent a dummy insert on a database level. So no text len>3 may enter this
field.
BR
Grega
________________________________
Od: Tom Lane <t...@sss.pgh.pa.us>
Poslano: 3. november 2021 18:37:28
Za: Grega Jesih
Kp: David G. Johnston; grega.je...@gmail.com; Pg Docs
Zadeva: Re: text fields and performance for ETL
Grega Jesih <grega.je...@actual-it.si> 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.
That's a matter for those tools to document, not us, because it's their
performance characteristics that you are talking about, not ours.
I'll just point out in passing, though, that "fixed record size" for text
strings is an illusion as soon as you have to deal with non-ASCII data.
So I'm skeptical that such optimizations are worth much anymore.
regards, tom lane
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.
