Re: reindex/vacuum locking/performance?

Поиск
Список
Период
Сортировка
От Matt Clark
Тема Re: reindex/vacuum locking/performance?
Дата
Msg-id LFEIJBEOKGPDHCEMDGNFMEOBCFAA.matt@ymogen.net
обсуждение исходный текст
Ответ на Re: reindex/vacuum locking/performance?  (Rob Nagler <nagler@bivio.biz>)
Ответы Re: reindex/vacuum locking/performance?  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-performance
> > vacuum full does require exclusive lock, plain vacuum does not.
>
> I think I need full, because there are updates on the table.  As I
> understand it, an update in pg is an insert/delete, so it needs
> to be garbage collected.

Yes and no.  You only need a plain VACUUM that is run often enough to
recover space as fast as you need to grab it.  For heavily updated tables
run it often - I run it every 5 minutes on some tables.  A VACUUM FULL is
only needed if you haven't been running VACUUM often enough in the first
place.

> The description of vacuum full implies that is required if the db
> is updated frequently.   This db gets about 1 txn a second, possibly
> more at peak load.

Assuming you mean 1 update/insert per second that is an absolutely _trivial_
load on any reasonable hardware.  You can do thousands of updates/second on
hardware costing less than $2000.  If you vacuum every hour then you will be
fine.

> IOW, vacuum+reindex is faster than dump+restore?  I didn't see this,
> then again, I had this locking problem, so the stats are distorted.

REINDEX also locks tables like VACUUM FULL.  Either is terribly slow, but
unless you turn off fsync during the restore it's unlikely to be slower than
dump & restore.

Matt


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

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: reindex/vacuum locking/performance?
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: reindex/vacuum locking/performance?