From: | "Alex Hunsaker" <badalex(at)gmail(dot)com> |
---|---|
To: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Significantly larger toast tables on 8.4? |
Date: | 2009-01-02 19:42:56 |
Message-ID: | 34d269d40901021142k43379b86x7c00ac6309d97b1d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 2, 2009 at 10:44, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Here, we have a case where the space savings are potentially much
> larger, and the only argument against it is that someone might be
> disappointed in the performance of substring operations, if they
> happen to do any. What if they know that they don't want to do any
> and want to get compression? Even if the benefit is only 1.5X on
> their data rather than 10X, that seems like a pretty sane and useful
> thing to want to do. It's easy to shut off compression if you don't
> want it; if the system makes an arbitrary decision to disable it, how
> do you get it back?
I think we could just add another toast storage type: alter table
alter column set storage compress; ? It seems overkill to expose
PGLZ_Strategy knobs per column...
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2009-01-02 19:50:34 | Re: Significantly larger toast tables on 8.4? |
Previous Message | Greg Smith | 2009-01-02 19:25:47 | Re: posix_fadvise v22 |