Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL vs MySQL

From: Jonathan Gardner <jgardner(at)jonathangardner(dot)net>
To: Dan Langille <dan(at)langille(dot)org>
Cc: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: PostgreSQL vs MySQL
Date: 2004-05-21 18:10:59
Message-ID: 200405211110.59955.jgardner@jonathangardner.net (view raw or flat)
Thread:
Lists: pgsql-advocacy
On Thursday 20 May 2004 01:08 pm, Dan Langille wrote:
> On Thu, 20 May 2004, Robert Treat wrote:
> > One potential issue with PostgreSQL and big databases would be
> > upgrades and backups, which require dumping lots of data to disk which
> > can be inconvenient. If I were a big company looking to switch to
> > postgresql, I'd think hard about using some of the money I saved in
> > license fee's to get in place upgrades developed.
>
> This is an issue frequently raised with Bacula (http://www.bacula.org/).
> How do I backup my 20GB database if I have only 1GB free diskspace?
> Bacula can use a FIFO, although I've never used it myself.

Interesting. I thought it was common knowledge never to exceed 75% of your 
resources, be it CPU, memory, disk, or network bandwidth. The extra 25% 
gives you time to upgrade without being rushed, and it allows for random 
peaks without depleting the resource. If someone allowed their database to 
grow to take 95% of their disk space, they have some serious problems.

But local backups -- that's just weird. I've seen backups being made 
locally, but then moved off the server on to some other data storage device 
(hard disk, tape drive, CD ROM) on another server. I've never seen anyone 
serious about their data trying to back up to the same disk the data is on.

-- 
Jonathan Gardner
jgardner(at)jonathangardner(dot)net

In response to

Responses

pgsql-advocacy by date

Next:From: Josh BerkusDate: 2004-05-21 18:15:11
Subject: Re: pgSQL deployment
Previous:From: Elein MustainDate: 2004-05-21 12:12:11
Subject: Re: email list for onsite oscon preparations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group