Re: PostgreSQL 8.2.3 VACUUM Timings/Performance

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
Дата
Msg-id 45EC4477.4020702@enterprisedb.com
обсуждение исходный текст
Ответ на PostgreSQL 8.2.3 VACUUM Timings/Performance  ("Bruce McAlister" <bruce.mcalister@blueface.ie>)
Список pgsql-performance
Aidan Van Dyk wrote:
> * Heikki Linnakangas <heikki@enterprisedb.com> [070305 09:46]:
>> In fact, getting rid of vacuum full, or changing it to work like
>> cluster, has been proposed in the past. The use case really is pretty
>> narrow; cluster is a lot faster if there's a lot of unused space in the
>> table, and if there's not, vacuum full isn't going to do much so there's
>> not much point running it in the first place. The reason it exists is
>> largely historical, there hasn't been a pressing reason to remove it either.
>
> I've never used CLUSTER, because I've always heard murmerings of it not
> being completely MVCC safe.  From the TODO:
>     * CLUSTER
>     o Make CLUSTER preserve recently-dead tuples per MVCC
>       requirements

Good point, I didn't remember that. Using cluster in an environment like
the OP has, cluster might actually break the consistency of concurrent
transactions.

> But the documents don't mention anything about cluster being unsafe.

Really? <checks docs>. Looks like you're right. Should definitely be
mentioned in the docs.

> AFAIK, Vacuum full doesn't suffer the same MVCC issues that cluster
> does.  Is this correct?

That's right. Vacuum full goes to great lengths to be MVCC-safe.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]