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 [EMAIL PROTECTED]
Copeland Computer Consulting
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
