From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | "Mario Weilguni" <mweilguni(at)sime(dot)com>, pgsql-performance(at)postgresql(dot)org, "Alexander Staubo" <alex(at)purefiction(dot)net>, "Ruben Rubio" <ruben(at)rentalia(dot)com> |
Subject: | Re: Optimization of this SQL sentence |
Date: | 2006-10-18 19:37:07 |
Message-ID: | b42b73150610181237r332d2f30ld48ff2b7f1f4d29@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 10/18/06, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
> On Tue, Oct 17, 2006 at 12:51:19PM -0400, Merlin Moncure wrote:
> > so, imo alexander is correct:
> > contacto varchar(255)
> >
> > ...is a false constraint, why exactly 255? is that were the dart landed?
>
> BTW, if we get variable-length varlena headers at some point, then
> setting certain limits might make sense to keep performance more
> consistent.
I would argue that it is assumptions about the underlying architecture
that got everyone into trouble in the first place :). I would prefer
to treat length constraint as a constraint (n + 1 = error), unless
there was a *compelling* reason to do otherwise, which currently there
isn't (or hasn't been since we got toast) a lot of this stuff s due
to legacy thinking, a lot of dbf products had limts to varchar around
255 or so.
imo, a proper constraint system would apply everything at the domain
level, and minlength and maxlength would get equal weight, and be
optional for all types.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Ioana Danes | 2006-10-18 19:51:34 | Postgresql 8.1.4 - performance issues for select on view using max |
Previous Message | Jim C. Nasby | 2006-10-18 19:19:01 | Re: Optimization of this SQL sentence (SOLVED) |