Re: cost-based vacuum

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: cost-based vacuum
Дата
Msg-id 1121093488.3970.70.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: cost-based vacuum  (Ian Westmacott <ianw@intellivid.com>)
Ответы Re: cost-based vacuum  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-performance
On Mon, 2005-07-11 at 09:07 -0400, Ian Westmacott wrote:
> On Mon, 2005-07-11 at 07:31, Simon Riggs wrote:
> > The ANALYZE commands hold read locks on the tables you wish to write to.
> > If you slow them down, you merely slow down your write transactions
> > also, and then the read transactions that wait behind them. Every time
> > the ANALYZE sleeps it wakes up the other transactions, which then
> > realise they can't move because of locks and then wake up the ANALYZEs
> > for another shot. The end result is that you introduce more context-
> > switching, without any chance of doing more useful work while the
> > ANALYZEs sleep.
>
> Let me make sure I understand.  ANALYZE acquires a read
> lock on the table, that it holds until the operation is
> complete (including any sleeps).  That read lock blocks
> the extension of that table via COPY.  Is that right?
>
> According to the 8.0 docs, ANALYZE acquires an ACCESS SHARE
> lock on the table, and that conflicts only with ACCESS
> EXCLUSIVE.  Thats why I didn't think I had a lock issue,
> since I think COPY only needs ROW EXCLUSIVE.  Or perhaps
> the transaction needs something more?

The docs are correct, but don't show catalog and buffer locks.

...but on further reading of the code there are no catalog locks or
buffer locks held across the sleep points. So, my explanation doesn't
work as an explanation for the sleep/no sleep difference you have
observed.

Best Regards, Simon Riggs





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

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: Question
Следующее
От: "Gregory S. Williamson"
Дата:
Сообщение: Re: Question