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@copelandconsulting.net>
Copeland Computer Consulting