Re: [mail] Re: 7.4 Wishlist

I'd like to show/register interest.

I can see it being very useful when combined with replication for situations
where the replicatiant databases are geographically seperated (i.e. Disaster
Recover sites or systems maintaining replicants in order to reduce the
distance from user to app to database). The bandwidth cost savings from
compressing the replication information would be immensly useful.

Al.

----- Original Message -----
From: "Joshua D. Drake" <jd@commandprompt.com>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Greg Copeland" <greg@CopelandConsulting.Net>; "Al Sutton"
<al@alsutton.com>; "Stephen L." <jleelim@hotmail.com>; "PostgresSQL Hackers
Mailing List" <pgsql-hackers@postgresql.org>
Sent: Tuesday, December 10, 2002 8:04 PM
Subject: Re: [mail] Re: [HACKERS] 7.4 Wishlist


> Hello,
>
>    We would probably be open to contributing it if there was interest.
> There wasn't interest initially.
>
> Sincerely,
>
> Joshua Drake
>
>
> Bruce Momjian wrote:
> > Greg Copeland wrote:
> >
> >>On Tue, 2002-12-10 at 11:25, Al Sutton wrote:
> >>
> >>>Would it be possible to make compression an optional thing, with the
default
> >>>being off?
> >>>
> >>
> >>I'm not sure.  You'd have to ask Command Prompt (Mammoth) or wait to see
> >>what appears.  What I originally had envisioned was a per database and
> >>user permission model which would better control use.  Since compression
> >>can be rather costly for some use cases, I also envisioned it being
> >>negotiated where only the user/database combo with permission would be
> >>able to turn it on.  I do recall that compression negotiation is part of
> >>the Mammoth implementation but I don't know if it's a simple capability
> >>negotiation or part of a larger scheme.
> >
> >
> > I haven't heard anything about them contributing it.  Doesn't mean it
> > will not happen, just that I haven't heard it.
> >
> > I am not excited about per-db/user compression because of the added
> > complexity of setting it up, and even set up, I can see cases where some
> > queries would want it, and others not.  I can see using GUC to control
> > this.  If you enable it and the client doesn't support it, it is a
> > no-op.  We have per-db and per-user settings, so GUC would allow such
> > control if you wish.
> >
> > Ideally, it would be a tri-valued parameter, that is ON, OFF, or AUTO,
> > meaning it would determine if there was value in the compression and do
> > it only when it would help.
> >
>
> --
> <COMPANY>CommandPrompt - http://www.commandprompt.com </COMPANY>
> <CONTACT>       <PHONE>+1.503.222-2783</PHONE>          </CONTACT>
>
>