Re: [GENERAL] Large databases, performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Large databases, performance
Дата
Msg-id 1928.1034087882@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Large databases, performance  (Ron Johnson <ron.l.johnson@cox.net>)
Ответы Re: [GENERAL] Large databases, performance  ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>)
Re: [GENERAL] Large databases, performance  (Ron Johnson <ron.l.johnson@cox.net>)
Список pgsql-performance
Ron Johnson <ron.l.johnson@cox.net> writes:
> Not only that, but you get INSERT, UPDATE, DELETE and SELECT performance
> gains with fixed length records, since you don't get fragmentation.

That argument loses a lot of its force when you consider that Postgres
uses non-overwriting storage management.  We never do an UPDATE in-place
anyway, and so it matters little whether the updated record is the same
size as the original.

>> Well, maybe. But since 7.1 or so char() and varchar() simply became text
>> with some length restrictions. This was one of the reasons. It also
>> simplified a lot of code.

> How much simpler can you get than fixed-length records?

It's not simpler: it's more complicated, because you need an additional
input item to figure out the size of any given column in a record.
Making sure that that info is available every place it's needed is one
of the costs of supporting a feature like this.

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Ron Johnson
Дата:
Сообщение: Re: [GENERAL] Large databases, performance
Следующее
От: "Shridhar Daithankar"
Дата:
Сообщение: Re: [GENERAL] Large databases, performance