From: | John Turner <fenwayriffs(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: B-tree index on a VARCHAR(4000) column |
Date: | 2017-09-10 18:00:59 |
Message-ID: | CAMAP1Q=J9wo2xNxk0Z+54YD8Yv7QTAYuHOcVk38=HaZULu+LvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Sep 10, 2017 at 10:42 AM Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> 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> wrote:
>>
>>> Ron Johnson <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.
>
> 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
John
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-10 18:24:47 | Re: B-tree index on a VARCHAR(4000) column |
Previous Message | Merlin Moncure | 2017-09-10 15:42:51 | Re: B-tree index on a VARCHAR(4000) column |