Re: best practices with index on varchar column

Поиск
Список
Период
Сортировка
Искать
От
Richard Huxton
Тема
Re: best practices with index on varchar column
Дата
Msg-id
42415390.8030208@archonet.com
Ответ на
Список
Дерево обсуждения
best practices with index on varchar column "Layet Benjamin" <benjamin@moonfactory.co.jp>
Re: best practices with index on varchar column Dawid Kuroczko <qnex42@gmail.com>
Re: best practices with index on varchar column PFC <lists@boutiquenumerique.com>
Re: best practices with index on varchar column Tom Lane <tgl@sss.pgh.pa.us>
Re: best practices with index on varchar column "Michael Ryan S. Puncia" <mpuncia@census.gov.ph>
Re: best practices with index on varchar column Dawid Kuroczko <qnex42@gmail.com>
Re: best practices with index on varchar column Richard Huxton <dev@archonet.com>
Dawid Kuroczko wrote:
> On Wed, 23 Mar 2005 12:11:56 +0800, Michael Ryan S. Puncia
>  wrote:
> 
>>I have an experience using LIKE in a VARCHAR column and select statement
>>suffers a lot so I decided to go back in CHAR

> According to the PostgreSQL's documentation:
> 
>      Tip: There are no performance differences between these three types,
> apart from the increased storage size when using the blank-padded type.
> While character(n) has performance advantages in some other database
> systems, it has no such advantages in PostgreSQL. In most situations text
> or character varying should be used instead.
> 
> 
> To my best knowledge char and varchar are stored in a same way
> (4-byte length plus textual value), so using char should make tables
> bigger in your case.  Then again, having each row exactly the same
> size makes it easier to delete and then later insert a new row in
> a same spot.  Am I thinking correct?  Is it a case where using char(n)
> makes that table avoid hmm fragmentation of some sort?

There aren't any noticeable differences between char and varchar. MVCC 
doesn't overwrite rows anyway, so static size is irrelevant. In any 
case, PG's toast setup splits out large text fields and compresses them 
- so it's not that simple.

-- 
   Richard Huxton
   Archonet Ltd
В списке pgsql-performance по дате отправления
От: Tambet Matiisen
Дата:
От: Tom Lane
Дата:
FAQ