From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Don Baccus <dhogaza(at)pacifier(dot)com> |
Cc: | Jan Wieck <wieck(at)debis(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] interesting observatation regarding views and V7.0 |
Date: | 2000-02-23 23:46:44 |
Message-ID: | 6017.951349604@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Don Baccus <dhogaza(at)pacifier(dot)com> writes:
>> Something else we might consider as a stopgap is to resurrect the
>> "compressed text" datatype that Jan wrote, and then removed in
>> anticipation of having TOAST.
> Also...interbase's "text" type is apparently compressed, and that's
> an interesting idea for "text" itself (as opposed to "varchar()" of
> a given size). Someone who just says "text" probably wants to be
> able to stuff as much text into the column as possible, I know
> I do!
Just quietly make text compressed-under-the-hood, you mean? Hmm.
Interesting idea, all right, and it wouldn't create any long-term
compatibility problem since users couldn't see it directly. I think
we might have some places in the system that assume char/varchar/text
all have the same internal representation, but that could probably
be fixed without too much grief.
> The price of compression/decompression is to some extent
> balanced by not having to drag as many bytes around during joins
> and sorts and the like.
Also, there could be a threshold: don't bother trying to compress
fields that are less than, say, 1K bytes.
Jan, what do you think? I might be able to find some time to try this,
if you approve of the idea but just don't have cycles to spare.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-02-24 00:04:54 | Re: [HACKERS] interesting observatation regarding views and V7.0 |
Previous Message | Tom Lane | 2000-02-23 23:38:29 | Re: [HACKERS] Cache query (PREPARE/EXECUTE) |