Re: why vacuum

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kenneth Gonsalves <lawgon(at)thenilgiris(dot)com>, PostgreSQL SQL <pgsql-sql(at)postgresql(dot)org>
Subject: Re: why vacuum
Date: 2005-10-26 16:18:36
Message-ID: 1130343516.2872.23.camel@state.g2switchworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Wed, 2005-10-26 at 11:12, Tom Lane wrote:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> > On Tue, 2005-10-25 at 23:45, Kenneth Gonsalves wrote:
> >> i was in a minor flame war with a mysql guy - his major grouse was that
> >> 'I wouldnt commit mission critical data to a database that needs to be
> >> vacuumed once a week'. So why does pg need vacuum?
>
> > Oh man oh man. After reading the article, I realized he was saying that
> > he wouldn't trust PostgreSQL to replace Oracle.
>
> Well, that's a slightly more respectable point of view, but Oracle has
> surely got its own set of gotchas ... doesn't it still have issues if
> you run a transaction that's large enough to overrun the fixed-size
> rollback areas (or whatever they call them)?

Yep, and it also has the "snapshot too old" issue for long running
transactions (long running meaning how many other things have happened
since it started, not length of time). Imagine starting a backup in
postgresql, getting an hour into it and suddenly it ends because
10,000,000 rows have been inserted while it was going. That kind of
error. My reply on that forum pointed out that EVERY database has
gotchas, and to pretend that your database's gotchas are ok but some
other database's gotchas are unacceptable is disingenuous at best.

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2005-10-26 16:39:12 Re: broken join optimization? (8.0)
Previous Message Michael Fuhr 2005-10-26 16:15:58 Re: Combining two SELECTs by same filters