From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Hannu Krosing <hannu(at)skype(dot)net> |
Cc: | Andrew Piskorski <atp(at)piskorski(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Compression and on-disk sorting |
Date: | 2006-05-17 20:20:07 |
Message-ID: | 20060517202007.GH26212@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Wed, May 17, 2006 at 10:55:19PM +0300, Hannu Krosing wrote:
> ??hel kenal p??eval, K, 2006-05-17 kell 10:01, kirjutas Jim C. Nasby:
> > If we're going to consider table-level compression, ISTM the logical
> > first step is to provide greater control over TOASTing; namely
> > thresholds for when to compress and/or go to external storage that can
> > be set on a per-field or at least per-table basis.
>
> also, we would get a lot of "compression", if we could get rid of index
> on toast table, and use the ctid directly.
It'd also be damn handy to be able to ditch the 2-pass vacuum
requirement. I've often wondered if treating the toast table as a real
table was overkill; for example, it should be possible to include WAL
information for it in with the parent table. That plus using ctid as a
reference would hopefully allow for removing a lot of overhead from it.
Presumably all the MVCC info could go, since that would be taken care of
by the parent table.
Of course the downside is that it'd mean a different set of code for
handling toast storage...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-05-17 20:31:05 | Re: PL/pgSQL 'i = i + 1' Syntax |
Previous Message | Jim C. Nasby | 2006-05-17 20:12:38 | Re: PL/pgSQL 'i = i + 1' Syntax |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-05-17 21:44:22 | Re: Compression and on-disk sorting |
Previous Message | Hannu Krosing | 2006-05-17 19:55:19 | Re: Compression and on-disk sorting |