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

From: John Turner <fenwayriffs(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
Cc: "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-08 22:37:06
Message-ID: CAMAP1QmuvGKjFqNtfxaYW-7EEw+bAjyoekyQ24PyOD6j2X9q2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nico Williams 2017-09-08 23:26:43 Re: Aquameta 0.1 - Request for reviews, contributors
Previous Message Nico Williams 2017-09-08 22:18:46 Re: Aquameta 0.1 - Request for reviews, contributors