Skip site navigation (1) Skip section navigation (2)

Re: Significantly larger toast tables on 8.4?

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 (view raw or flat)
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...

In response to

Responses

pgsql-hackers by date

Next:From: Alex HunsakerDate: 2009-01-02 19:50:34
Subject: Re: Significantly larger toast tables on 8.4?
Previous:From: Greg SmithDate: 2009-01-02 19:25:47
Subject: Re: posix_fadvise v22

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group