From: Peter Schuller <peter.schuller@infidyne.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: VACUUM ANALYZE blocking both reads and writes to a table
Date: Mon, 30 Jun 2008 17:43:18 +0200
Message-ID: <20080630154318.GB15756@hyperion.scode.org> (raw)
In-Reply-To: <20080630152515.GF10311@alvh.no-ip.org>
References: <20080630145903.GA15197@hyperion.scode.org>
<20080630152515.GF10311@alvh.no-ip.org>
Actually, while on the topic:
> date: 2007-09-10 13:58:50 -0400; author: alvherre; state: Exp; lines: +6 -2;
> Remove the vacuum_delay_point call in count_nondeletable_pages, because we hold
> an exclusive lock on the table at this point, which we want to release as soon
> as possible. This is called in the phase of lazy vacuum where we truncate the
> empty pages at the end of the table.
Even with the fix the lock is held. Is the operation expected to be
"fast" (for some definition of "fast") and in-memory, or is this
something that causes significant disk I/O and/or scales badly with
table size or similar?
I.e., is this enough that, even without the .4 bug, one should not
really consider VACUUM ANALYZE non-blocking with respect to other
transactions?
(I realize various exclusive locks are taken for short periods of time
even for things that are officially declared non-blocking; the
question is whether this falls into this category.)
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: peter.schuller@infidyne.com, alvherre@commandprompt.com
Subject: Re: VACUUM ANALYZE blocking both reads and writes to a table
In-Reply-To: <20080630154318.GB15756@hyperion.scode.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox