Re: [GENERAL] B-tree index on a VARCHAR(4000) column
| От | Merlin Moncure |
|---|---|
| Тема | Re: [GENERAL] B-tree index on a VARCHAR(4000) column |
| Дата | |
| Msg-id | CAHyXU0xE_54MQxs-_jk84UxEHigFsBstPJNouv-yu=19Wi8_RQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | 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
|
| Список | pgsql-general |
On Friday, September 8, 2017, John Turner <fenwayriffs@gmail.com> wrote:
On Fri, Sep 8, 2017 at 6:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:Ron Johnson <ron.l.johnson@cox.net> writes:
> Based on LENGTH(offending_column), none of the values are more than 144
> bytes in this 44.2M row table. Even though VARCHAR is, by definition,
> variable length, are there any internal design issues which would make
> things more efficient if it were dropped to, for example, VARCHAR(256)?
No.So the declarative column length has no bearing on memory grants during plan generation/execution?
Nope. Memory usage is proportional to the size of the string, not the maximum length for varchar. Maximum length is a constraint.
merlin
В списке pgsql-general по дате отправления: