From: Florian Weimer <fweimer@bfk.de>
To: Jeremy Haile <jhaile@fastmail.fm>
Cc: pgsql-performance@postgresql.org
Subject: Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
Date: Wed, 10 Jan 2007 10:33:53 +0100
Message-ID: <82vejfi5tq.fsf@mid.bfk.de> (raw)
In-Reply-To: <1168373668.28926.1168412995@webmail.messagingengine.com>
References: <1168363601.5177.1168380907@webmail.messagingengine.com>
<82d55okrim.fsf@mid.bfk.de>
<1168373668.28926.1168412995@webmail.messagingengine.com>
* Jeremy Haile:
> Good advice on the partitioning idea. I may have to restructure some of
> my queries, since some of them query across the whole range - but it may
> be a much more performant solution. How is the performance when
> querying across a set of partitioned tables vs. querying on a single
> table with all rows?
Locality of access decreases, of course, and depending on your data
size, you hit something like to 2 or 4 additional disk seeks per
partition for index-based accesses. Sequential scans are not
impacted.
> Does my current approach of disabling autovacuum and manually vacuuming
> once-an-hour sound like a good idea, or would I likely have better
> results by auto-vacuuming and turning row-level stats back on?
Sorry, I haven't got much experience with autovacuum, since most of
other databases are INSERT-only (or get VACUUMed automatically after
major updates).
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
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: fweimer@bfk.de, jhaile@fastmail.fm
Subject: Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
In-Reply-To: <82vejfi5tq.fsf@mid.bfk.de>
* 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