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

On Friday, September 8, 2017, John Turner <fenwayriffs(at)gmail(dot)com> wrote:

>
>
> On Fri, Sep 8, 2017 at 6:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <javascript:_e(%7B%7D,'cvml','tgl(at)sss(dot)pgh(dot)pa(dot)us');>> wrote:
>
>> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net
>> <javascript:_e(%7B%7D,'cvml','ron(dot)l(dot)johnson(at)cox(dot)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