Re: why vacuum - Mailing list pgsql-sql

From Scott Marlowe
Subject Re: why vacuum
Date
Msg-id 1130337891.2872.8.camel@state.g2switchworks.com
Whole thread Raw
In response to why vacuum  (Kenneth Gonsalves <lawgon@thenilgiris.com>)
Responses Re: why vacuum
List pgsql-sql
On Tue, 2005-10-25 at 23:45, Kenneth Gonsalves wrote:
> hi,
> 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?

The absolutely funniest thing about what this guy is saying is that he
seems rather ignorant of the behaviour of innodb tables.  They have
another name for the vacuum command there.  It's:

ALTER TABLE tbl_name ENGINE=INNODB

Which rebuilds the whole fraggin's table, with an exclusive lock.

and guess what innodb does if you don't run this command every so often?

Can you guess yet?  Yep, that's right, it just keeps growing and growing
and growing.

Hell, innodb isn't any better than the original mvcc implementation
postgresql had when vacuums were all full and took exclusive locks.

But at least with PostgreSQL it was a well documented issue, and was
mentioned in the administrative section of the docs, so you knew you had
to do it.  It's kind of tucked away in the innodb section of the mysql
docs, and most mysql folks don't even know they need to do it, since
they almost all use myisam table types.

If someone is more worried about postgresql's non-blocking, easily
scheduled vacuuming, but is using myisam tables, and a database that by
default allows numeric overflows to just insert the maximum possible
value, I wouldn't trust them with handling my paycheck with their
fan-boy database.


pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: RETURNS SETOF primitive returns results in parentheses
Next
From: Stephan Szabo
Date:
Subject: Re: RETURNS SETOF primitive returns results in parentheses