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

2017-09-10 Thread John Turner
On Sun, Sep 10, 2017 at 1:24 PM Tom Lane wrote: > > For every other purpose, PG just pays attention to the actual column > values' lengths. > > Thanks for elaborating, Tom. This would appear to be a(nother) case where PG represents the voice of sanity as compared with 'the other guys' : ) John

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

2017-09-10 Thread Tom Lane
John Turner writes: > On Sun, Sep 10, 2017 at 10:42 AM Merlin Moncure 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

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

2017-09-10 Thread John Turner
On Sun, Sep 10, 2017 at 10:42 AM Merlin Moncure wrote: > On Friday, September 8, 2017, John Turner wrote: > >> >> >> On Fri, Sep 8, 2017 at 6:57 AM Tom Lane wrote: >> >>> Ron Johnson writes: >>> > Based on LENGTH(offending_column), none of the values are more than 144 >>> > bytes in this 44.2M

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

2017-09-10 Thread Merlin Moncure
On Friday, September 8, 2017, John Turner wrote: > > > On Fri, Sep 8, 2017 at 6:57 AM Tom Lane > wrote: > >> Ron Johnson > > 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, >> > varia

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

2017-09-08 Thread John Turner
On Fri, Sep 8, 2017 at 6:57 AM Tom Lane wrote: > Ron Johnson 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 >

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

2017-09-08 Thread Merlin Moncure
On Thu, Sep 7, 2017 at 10:48 PM, Ron Johnson wrote: > Hi, > > v 9.2.7 > > 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 > thin

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

2017-09-08 Thread Tom Lane
Ron Johnson 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 exam