Mike Nolan <[EMAIL PROTECTED]> writes:
>> Can't you just create a TEXT(255) field same as you can just create
>> VARCHAR (with no length) field? I think they're basically synonyms for
>> each other these days.
> I'll defer to the SQL standard gurus on this, as well as to the internals
> guys,
Mike Nolan <[EMAIL PROTECTED]> writes:
>> Frankly, the only reason to use anything other than TEXT is
>> compatibility with other databases and applications.
> You don't consider a requirement that a field be no longer than a
> certain length a reason not to use TEXT?
If you have an actual bus
> >>You don't consider a requirement that a field be no longer than a
> >>certain length a reason not to use TEXT?
>
> Can't you just create a TEXT(255) field same as you can just create
> VARCHAR (with no length) field? I think they're basically synonyms for
> each other these days.
I'll
On Fri, 2004-03-05 at 18:43, Mike Nolan wrote:
> > Frankly, the only reason to use anything other than TEXT is compatibility with
> > other databases and applications.
>
> You don't consider a requirement that a field be no longer than a
> certain length a reason not to use TEXT?
Actually, I
> Frankly, the only reason to use anything other than TEXT is compatibility with
> other databases and applications.
You don't consider a requirement that a field be no longer than a
certain length a reason not to use TEXT?
--
Mike Nolan
---(end of broadcast)--
Jeff:
> As far as I know there is only a small win when you want to extract some
> field from a tuple and with variable width fields you have to walk to the
> correct field. But this is a small performance problem unless you have
> very many variable size columns in the table.
BTW, Dennis here is
Jeff, Bill:
> No. The user docs state that the performance is equal for char, varchar
> and text.
Actually, CHAR is slightly *slower* than VARCHAR or TEXT for SELECTs in many
applications. This is becuase of the field padding, and the frequent
necessity of casting CHAR::TEXT and back.
For I
On Fri, 5 Mar 2004, Jeff wrote:
> Is there any performance advantage to using a fixed width row (with PG)?
As far as I know there is only a small win when you want to extract some
field from a tuple and with variable width fields you have to walk to the
correct field. But this is a small performa
Jeff wrote:
I'm guessing the answer to this is "no"
Is there any performance advantage to using a fixed width row (with PG)?
No. The user docs state that the performance is equal for char, varchar
and text.
I've heard this theory a few times and I think it is based on older,
different databases
I'm guessing the answer to this is "no"
Is there any performance advantage to using a fixed width row (with PG)?
I've heard this theory a few times and I think it is based on older,
different databases and we have also some custom software here that
uses fixed width rows to be able to hit row N
10 matches
Mail list logo
