Re: cost-based vacuum

From: Ian Westmacott <ianw(at)intellivid(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: cost-based vacuum
Date: 2005-07-11 13:07:46
Message-ID: 1121087266.27427.35.camel@spectre.intellivid.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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?

Thanks,

--Ian

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-07-11 13:28:52 Re: cost-based vacuum
Previous Message Alejandro Lemus 2005-07-11 12:59:51 Question