Re: [GENERAL] B-tree index on a VARCHAR(4000) column

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] B-tree index on a VARCHAR(4000) column
Дата
Msg-id 21945.1505067887@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] B-tree index on a VARCHAR(4000) column  (John Turner <fenwayriffs@gmail.com>)
Ответы Re: [GENERAL] B-tree index on a VARCHAR(4000) column  (John Turner <fenwayriffs@gmail.com>)
Список pgsql-general
John Turner <fenwayriffs@gmail.com> writes:
> On Sun, Sep 10, 2017 at 10:42 AM Merlin Moncure <mmoncure@gmail.com> wrote:
>> Nope.  Memory usage is proportional to the size of the string, not the
>> maximum length for varchar.  Maximum length is a constraint.

> Ok, thanks for verifying.  I was curious since other platforms seem to
> handle this aspect of memory allocation differently (more crudely, perhaps)
> based on estimation of how fully populated the column _might_ be given a
> size constraint:
> https://sqlperformance.com/2017/06/sql-plan/performance-myths-oversizing-strings

AFAIR, the only way in which a different declared max column length would
affect Postgres' behavior like that is that, depending on what other
columns are in the table, it might be able to prove that it doesn't need
to create a "toast table" for the table, because no row in the table could
ever be wide enough to require toasting.  That would save a few
microseconds during table creation and drop ... but an unused toast table
that's just sitting there is surely not much overhead.

For every other purpose, PG just pays attention to the actual column
values' lengths.
        regards, tom lane


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

Предыдущее
От: John Turner
Дата:
Сообщение: Re: [GENERAL] B-tree index on a VARCHAR(4000) column
Следующее
От: techmail+pgsql@dangertoaster.com
Дата:
Сообщение: Re: [GENERAL] pg_ident mapping Kerberos Usernames