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
