On Tue, 2002-12-10 at 13:38, Bruce Momjian wrote: > I haven't heard anything about them contributing it. Doesn't mean it > will not happen, just that I haven't heard it. >
This was in non-mailing list emails that I was told this by Joshua Drake at Command Prompt. Of course, that doesn't have to mean it will be donated for sure but nonetheless, I was told it will be. Here's a quote from one of the emails. I don't think I'll be too far out of line posting this. On August 9, 2002, Joshua Drake said, "One we plan on releasing this code to the developers after 7.3 comes out. We want to be good members of the community but we have to keep a slight commercial edge (wait to you see what we are going to do to vacuum)." Obviously, I don't think that was official speak, so I'm not holding them to the fire, nonetheless, that's what was said. Additional follow ups did seem to imply that they were very serious about this and REALLY want to play nice as good shared source citizens. > 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. > I never thought beyond the need for what form an actual implementation of this aspect would look like. The reason for such a concept would be to simply limit the number of users that can be granted compression. If you have a large user base all using compression or even a small user base where very large result sets are common, I can imagine your database server becoming CPU bound. The database/user thinking was an effort to allow the DBA to better manage the CPU effect. > 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. Yes, that makes sense and was something I had originally envisioned. Simply stated, some installations may never want compression while others may want it for every connection. Beyond that, I believe there needs to be something of a happy medium where a DBA can better control who and what is taking his CPU away (e.g. only that one remote location being fed via ISDN). If GUC can fully satisfy, I certainly won't argue against it. -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
