Re: postgre vs MySQL

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, paul rivers <rivers(dot)paul(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: postgre vs MySQL
Date: 2008-03-13 19:02:36
Message-ID: 47D97A4C.4040308@pinpointresearch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


> Currently postgresql's "vacuum full" also locks the affected tables.
> Does 8.3 vacuum full effectively make a copy of the entire table? How
> much extra space will the various vacuums use while vacuuming?
>
As to 8.3 and how it handles vacuum-full internally, I can't say for
certain without reading the notes. I suspect it is an in-place operation
similar to prior versions.

But if you are running PG 7.0 or later (maybe even earlier, I didn't
look) and have enough disk space to replicate the table, you can use
CLUSTER to do a copy-to-new file and delete old file operation. It does
still lock the table and it does require that the table have an index
based on which it will physically reorder the table but it is usually
_way_ faster and you get fresh indexes as a bonus.

IOW, PG offers you the choice to pick whichever is best for you.

Cheers,
Steve

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2008-03-13 19:06:15 Re: Segmentation fault (core dumped) loading data on 8.3 upgrade: undefined symbol 'pg_valid_server_encoding_id', lazy binding failed!
Previous Message Tom Lane 2008-03-13 19:02:28 Re: Can't rename an existnig DB because it doesn't exist???