On Fri, 2021-06-18 at 10:28 +1000, Gavan Schneider wrote:
> On 18 Jun 2021, at 9:34, David G. Johnston wrote:
> > On Thursday, June 17, 2021, Gavan Schneider
> > wrote:
> >
> > > My approach is to define such fields as ‘text’ and set a constraint using
> > > char_length(). This allows PG to do t
On 18 Jun 2021, at 9:34, David G. Johnston wrote:
> On Thursday, June 17, 2021, Gavan Schneider
> wrote:
>
>>
>> My approach is to define such fields as ‘text’ and set a constraint using
>> char_length(). This allows PG to do the business with the text in native
>> form, and only imposes the cost
On Thursday, June 17, 2021, Gavan Schneider
wrote:
>
> My approach is to define such fields as ‘text’ and set a constraint using
> char_length(). This allows PG to do the business with the text in native
> form, and only imposes the cost of any length check when the field is
> updated… best of bo
On 17 Jun 2021, at 1:08, Tom Lane wrote:
> Martin Mueller writes:
>
>> Are there performance issues with the choice of 'text' vs. varchar and some
>> character limit? For instance, if I have a table with ten million records
>> and text fields that may range in length from 15 to 150, can I expe
Martin Mueller writes:
> Are there performance issues with the choice of 'text' vs. varchar and some
> character limit? For instance, if I have a table with ten million records
> and text fields that may range in length from 15 to 150, can I expect a
> measurable improvement in response time f
Are there performance issues with the choice of 'text' vs. varchar and some
character limit? For instance, if I have a table with ten million records and
text fields that may range in length from 15 to 150, can I expect a measurable
improvement in response time for using varchar(150) or will t
