Re: [mail] Re: 7.4 Wishlist

From: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
To: Kyle <kaf(at)nwlink(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Al Sutton <al(at)alsutton(dot)com>, "Stephen L(dot)" <jleelim(at)hotmail(dot)com>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Subject: Re: [mail] Re: 7.4 Wishlist
Date: 2002-12-11 01:15:54
Message-ID: 1039569354.4594.96.camel@mouse.copelandconsulting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-general pgsql-hackers

This has been brought up a couple of times now. Feel free to search the
old archives for more information. IIRC, it would of made the
implementation more problematic, or so I think it was said.

When I originally brought the topic (compression) up, it was not well
received. As such, it may of been thought that additional effort on
such an implementation would not be worth the return on a feature which
most seemingly didn't see any purpose in supporting in the first place.
You need to keep in mind that many simply advocated using a compressing
ssh tunnel.

Seems views may of changed some since then so it may be worth
revisiting. Admittedly, I have no idea what would be required to move
the toast data all the way through like that. Any idea? Implementing a
compression stream (which seems like what was done for Mammoth) or even
packet level compression were both something that I could comfortably
put my arms around in a timely manner. Moving toast data around wasn't.

Greg

On Tue, 2002-12-10 at 18:45, Kyle wrote:
> Without getting into too many details, why not send toast data to
> non-local clients? Seems that would be the big win. The data is
> already compressed, so the server wouldn't pay cpu time to recompress
> anything. And since toast data is relatively large anyway, it's the
> stuff you'd want to compress before putting it on the wire anyway.
>
> If this is remotely possible let me know, I might be interested in
> taking a look at it.
>
> -Kyle
>
> Bruce Momjian wrote:
> >
> > 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.

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Al Sutton 2002-12-11 07:16:10 Re: [mail] Re: 7.4 Wishlist
Previous Message Kyle 2002-12-11 00:45:51 Re: [mail] Re: 7.4 Wishlist

Browse pgsql-general by date

  From Date Subject
Next Message Omid Mahboubi 2002-12-11 01:45:08 serial data type
Previous Message Kyle 2002-12-11 00:45:51 Re: [mail] Re: 7.4 Wishlist

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-12-11 01:55:59 Re: PQnotifies() in 7.3 broken?
Previous Message Kyle 2002-12-11 00:45:51 Re: [mail] Re: 7.4 Wishlist