Re: How to do faster DML - Mailing list pgsql-general

From veem v
Subject Re: How to do faster DML
Date
Msg-id CAB+=1TUfaoFXhuFWhzRZnT8HMPGZwa4Ek+33iV2KmBpDZcDdtA@mail.gmail.com
Whole thread Raw
In response to Re: How to do faster DML  (Ron Johnson <ronljohnsonjr@gmail.com>)
List pgsql-general

On Tue, 13 Feb 2024 at 02:01, Ron Johnson <ronljohnsonjr@gmail.com> wrote:
On Mon, Feb 12, 2024 at 3:23 PM veem v <veema0000@gmail.com> wrote:
[snip] 
So it looks like the fixed length data type(like integer, float) should be the first choice while choosing the data type of the attributes wherever possible, as these are native types.

Correct.
 
(Like choosing "Integer/float" over "Numeric", "Char" over "Varchar" etc). 
However I do see even in Oracle databases, we have Integer type too, but it's suggesting(For e.g. in below blog) to rather go with Number types over Integer and Varchar2 over Char, which is opposite of what we are discussing here. Is the fixed length data type behaves differently in postgres vs oracle and thus should be treated differently?



From above blog:-

Oracle is not Postgresql.  WTH are you using an Oracle blog to decide on Postgresql data types????
 

When to use CHAR: There should be no reason to use the CHAR data type, as it is similar to a VARCHAR2 and it’s better to be consistent.
When to use INTEGER: You should use the NUMBER data type instead.


Did you actually read that blog post?

Have you even read the Postgresql documentation on data types?
 

My Apology, If interpreting wrongly. My thought was that , as fixed length data types are native type ones, ideally it should be faster in all the databases. So was comparing with different databases. And mainly as I had worked mainly in Oracle database in the past and so it was a key learning here and seemed totally opposite, so was curious to know.

Regards
Veem

  

pgsql-general by date:

Previous
From: Ron Johnson
Date:
Subject: Re: How to do faster DML
Next
From: Adrian Garcia Badaracco
Date:
Subject: Compressing large column by moving it to a unique table