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
ifvolume 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@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
