Re: How to do faster DML

Поиск
Список
Период
Сортировка
От veem v
Тема Re: How to do faster DML
Дата
Msg-id CAB+=1TUfaoFXhuFWhzRZnT8HMPGZwa4Ek+33iV2KmBpDZcDdtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: How to do faster DML  (Ron Johnson <ronljohnsonjr@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Ron Johnson
Дата:
Сообщение: Re: How to do faster DML
Следующее
От: Adrian Garcia Badaracco
Дата:
Сообщение: Compressing large column by moving it to a unique table