Re: OT Bull-fight avoidance

From: Marshall <marshall.spight_at_gmail.com>
Date: 29 May 2006 09:52:24 -0700
Message-ID: <1148921543.941589.171440_at_38g2000cwa.googlegroups.com>


Bob Badour wrote:
> Alfredo Novoa wrote:
> > Keith wrote:
> >
> >>The performance advantages of size constraints is
> >>fundamental.
> >
> > Only with lazy implementations.
>
> Alfredo, the performance advantages of size constraints are fundamental
> regardless--as are the performance disadvantages.

It seems to me that the integrity-enforcement value of a max length well exceeds the performance value.

The performance value doesn't seem so great to me. The one circumstance in which it would seem more than trivial would be where the dbms could store a varchar inline with the rest of the fields, vs. in a separate heap. (But I know virtually nothing about database internals, so I could be way off.) That seems like it would be a significant win.

But at least some DBMSs have separate varchar types for 2^8 chars, 2^16, 2^24, and 2^32. I don't see much of a win in doing so. The one advantage I can imagine for this would be being able to use smaller pointers/offsets, which would then use less storage. But I don't see where a dbms would need to be storing pointers/offsets into a varchar, so wtf? And if we are talking about the implementation of library code for functions on varchars, I'd expect them all to use 32 bit pointers for traversing the attribute value, regardless of the max size of the type.

Another, unrelated point that hasn't been mentioned so far (although I might have missed it; thread fatigue setting in...) is that in fact, a variety of non-mandatory performance tuning options is an indicator of technical *maturity* of a product, and we might well ask why another product or family of products *didn't* have such.

Marshall Received on Mon May 29 2006 - 18:52:24 CEST

Original text of this message