Bruce Momjian wrote:
>
> I see in the data types section for character types this text:
>
> There are no performance differences between these three types,
> apart from the increased storage size when using the blank-padded
> type.
>
> I can't improve on that.
I added a mention
I see in the data types section for character types this text:
There are no performance differences between these three types,
apart from the increased storage size when using the blank-padded
type.
I can't improve on that.
---
On Thu, 4 Jul 2002, Tom Lane wrote:
> I can think of very very few applications where CHAR(n) is really a
> sensible choice over VARCHAR(n).
text hashes such as MD5 and crypt, stock or serial numbers, automotive
VIN codes, invoice sequences, emulated bitmasks, etc. Lots of
industry-specific
At 04:49 PM 7/4/2002, Tom Lane wrote:
>John Moore <[EMAIL PROTECTED]> writes:
> > So I *suspect* I want to keep the data in the physical row, rather than
> > using TEXT and having it stored separately from the record.
>
>You seem to be reading something into the TEXT type that's not there;
>perhap
John Moore <[EMAIL PROTECTED]> writes:
> So I *suspect* I want to keep the data in the physical row, rather than
> using TEXT and having it stored separately from the record.
You seem to be reading something into the TEXT type that's not there;
perhaps you are carrying over associations from som
>If you don't want a limit, use TEXT. Long values are automatically
>stored in TOAST tables to avoid performance problems with sequential
>scans over long row values.
Thanks...
I wasn't quite clear enough in my question I am focused on OLTP
performance, and in my case the vast majority o
John Moore wrote:
> We have a need to store text data which typically is just a hundred or so
> bytes, but in some cases may extend to a few thousand. Our current field
> has a varchar of 1024, which is not large enough. Key data is fixed sized
> and much smaller in this same record.
>
> Our a
