Re: fixed-length row

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: fixed-length row
Дата
Msg-id
22409.1074182095@sss.pgh.pa.us
Ответ на
fixed-length row (David Garamond)
Список
Дерево обсуждения
fixed-length row David Garamond <lists@zara.6.isreserved.com>
Re: fixed-length row Richard Huxton <dev@archonet.com>
Re: fixed-length row Bruce Momjian <pgman@candle.pha.pa.us>
Re: fixed-length row Martijn van Oosterhout <kleptog@svana.org>
Re: fixed-length row David Garamond <lists@zara.6.isreserved.com>
Re: fixed-length row Tom Lane <tgl@sss.pgh.pa.us>
David Garamond  writes:
> The MySQL manual recommends that we create a "fixed-length row" if 
> possible, for speed (especially scanning speed).

> Is there a similar recommendation in PostgreSQL?

No.  There are some marginal optimizations that take place if your
columns are fixed-width and not null, but I wouldn't suggest contorting
your database design to enable them to occur.

In particular, people who have taken this bait generally think that
it's a good idea to substitute char(n) for varchar(n).  That is almost
inevitably a pessimization, because the extra I/O time for all those
padding blanks will surely swamp the few CPU cycles saved by using
precalculated field offsets.  (Not to mention that char(n) is not really
fixed-width anyway, in Postgres or any other implementation that
supports variable-length character encodings.)

I'd be willing to speculate that the MySQL manual's advice is bad
even for MySQL, but I haven't benchmarked the case there.

			regards, tom lane
В списке pgsql-general по дате отправления
От: Karsten Hilbert
Дата:
От: Stephan Szabo
Дата:
FAQ