Re: Client/Server compression?

Greg Copeland wrote:
> On Thu, 2002-03-14 at 14:03, Arguile wrote:
>
> [snip]
>
> > I'm sceptical of the benefit such compressions would provide in this setting
> > though. We're dealing with sets that would have to be compressed every time
> > (no caching) which might be a bit expensive on a database server. Having it
> > as a default off option for psql migtht be nice, but I wonder if it's worth
> > the time, effort, and cpu cycles.
> >
>
> I dunno. That's a good question. For now, I'm making what tends to be
> a safe assumption (opps...that word), that most database servers will be
> I/O bound rather than CPU bound. *IF* that assumption hold true, it

If you have too much CPU idle time you wasted money by
oversizing the machine. And as soon as you add SORT BY to
your queries, you'll see some CPU used.

I only make the assumption that whenever there is a database
server, there is an application server as well (or multiple
of them). Scenarios that require direct end-user connectivity
to the database server (alas Access->MSSQL) should NOT be
encouraged.

The db and app should be very close together, coupled with a
dedicated backbone net. No need for encryption, and if volume
is a problem, gigabit is the answer.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com