Re: Repair cosmetic damage (done by pg_indent?) - Mailing list pgsql-patches

From Decibel!
Subject Re: Repair cosmetic damage (done by pg_indent?)
Date
Msg-id 20070804000335.GZ25704@nasby.net
Whole thread Raw
In response to Re: Repair cosmetic damage (done by pg_indent?)  (Decibel! <decibel@decibel.org>)
List 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@decibel.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@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Attachment

pgsql-patches by date:

Previous
From: Decibel!
Date:
Subject: Re: strpos() && KMP
Next
From: Andrew Dunstan
Date:
Subject: Re: COPYable logs