On Tue, 2002-12-10 at 11:25, Al Sutton wrote:
> Would it be possible to make compression an optional thing, with the default
> being off?
>
I'm not sure. You'd have to ask Command Prompt (Mammoth) or wait to see
what appears. What I originally had envisioned was a per database and
user permission model which would better control use. Since compression
can be rather costly for some use cases, I also envisioned it being
negotiated where only the user/database combo with permission would be
able to turn it on. I do recall that compression negotiation is part of
the Mammoth implementation but I don't know if it's a simple capability
negotiation or part of a larger scheme.
The reason I originally imagined a user/database type approach is
because I would think only a subset of a typical installation would be
needing compression. As such, this would help prevent users from
arbitrarily chewing up database CPU compressing data because:
o datasets are uncompressable or poorly compresses
o environment cpu is at a premium
o is in a bandwidth rich environment
> I'm in a position that many others may be in where the link between my app
> server and my database server isn't the bottleneck, and thus any time spent
> by the CPU performing compression and decompression tasks is CPU time that
> is in effect wasted.
Agreed. This is why I'd *guess* that Mammoth's implementation does not
force compression.
>
> If a database is handling numerous small queries/updates and the
> request/response packets are compressed individually, then the overhead of
> compression and decompression may result in slower performance compared to
> leaving the request/response packets uncompressed.
Again, this is where I'm gray on their exact implementation. It's
possible they implemented a compressed stream even though I'm hoping
they implemented a per packet compression scheme (because adaptive
compression becomes much more capable and powerful; in both
algorithmically and logistical use). An example of this would be to
avoid any compression on trivially sized result sets. Again, this is
another area where I can imagine some tunable parameters.
Just to be on the safe side, I'm cc'ing Josh Drake at Command Prompt
(Mammoth) to see what they can offer up on it. Hope you guys don't
mind.
Greg
> ----- Original Message -----
> From: "Greg Copeland" <[EMAIL PROTECTED]>
> To: "Stephen L." <[EMAIL PROTECTED]>
> Cc: "PostgresSQL Hackers Mailing List" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 10, 2002 4:56 PM
> Subject: [mail] Re: [HACKERS] 7.4 Wishlist
>
>
> > On Tue, 2002-12-10 at 09:36, Stephen L. wrote:
> > > 6. Compression between client/server interface like in MySQL
> > >
> >
> > Mammoth is supposed to be donating their compression efforts back to
> > this project, or so I've been told. I'm not exactly sure of their
> > time-line as I've slept since my last conversation with them. The
> > initial feedback that I've gotten back from them on this subject is that
> > the compression has been working wonderfully for them with excellent
> > results. IIRC, in their last official release, they announced their
> > compression implementation. So, I'd think that it would be available
> > for 7.4 of 7.5 time frame.
> >
> >
> > --
> > Greg Copeland <[EMAIL PROTECTED]>
> > Copeland Computer Consulting
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
