Re: [mail] Re: 7.4 Wishlist

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 <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting