Re: Repair cosmetic damage (done by pg_indent?)

From: Decibel! <decibel(at)decibel(dot)org>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Repair cosmetic damage (done by pg_indent?)
Date: 2007-08-04 00:03:35
Message-ID: 20070804000335.GZ25704@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Fri, Aug 03, 2007 at 06:12:09PM -0500, Decibel! wrote:
> On Sun, Jul 29, 2007 at 12:06:50PM +0100, Gregory Stark wrote:
> > "Decibel!" <decibel(at)decibel(dot)org> writes:
> >
> > > On Fri, Jul 27, 2007 at 04:07:01PM +0100, Gregory Stark wrote:
> > >> Fwiw, do we really not want to compress anything smaller than 256 bytes
> > >> (everyone in Postgres uses the default strategy, not the always strategy).
> > >
> > > Is there actually a way to specify always compressing? I'm not seeing it
> > > on http://www.postgresql.org/docs/8.2/interactive/storage-toast.html
> >
> > In the code there's an "always" strategy, but nothing in Postgres uses it so
> > there's no way to set it using ALTER TABLE ... SET STORAGE.
> >
> > That might be an interesting approach though. We could add another SET STORAGE
> > value "COMPRESSIBLE" which says to use the always strategy. The neat thing
> > about this is we could set bpchar to use this storage type by default.
>
> Yeah, we should have that. I'll add it to my TODO...

On second thought... how much work would it be to expose the first 3 (or
even all) of the elements in PGLZ_Strategy to SET STORAGE? It's
certainly possible that there are workloads out there that will never be
optimal with one of our pre-defined strategies...
--
Decibel!, aka Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2007-08-04 01:26:22 Re: COPYable logs
Previous Message Decibel! 2007-08-03 23:41:03 Re: strpos() && KMP