From: Tom Lane <tgl@sss.pgh.pa.us>
To: Russell Smith <mr-russ@pws.com.au>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org
Subject: Re: Heavy write activity on first vacuum of fresh TOAST data
Date: Fri, 14 Dec 2007 02:42:42 -0500
Message-ID: <29185.1197618162@sss.pgh.pa.us> (raw)
In-Reply-To: <47623103.7030700@pws.com.au>
References: <4760FF69.EE98.0025.0@wicourts.gov>
<1197562283.4255.1829.camel@ebony.site>
<47611B9D.EE98.0025.0@wicourts.gov>
<1197569564.4255.1855.camel@ebony.site>
<47614D86.EE98.0025.0@wicourts.gov>
<1197582010.4255.1912.camel@ebony.site>
<47623103.7030700@pws.com.au>
Russell Smith <mr-russ@pws.com.au> writes:
> Given vacuum must then touch every page, is there a win in only setting
> hint bits on pages where vacuum has to do some other work on the page?
> As vacuum is causing significant IO load for data that may not be
> accessed for some time.
Well, if vacuum doesn't do it then some other poor sod will have to.
My feeling is that vacuum's purpose in life is to offload maintenance
cycles from foreground queries, so we should be happy to have it setting
all the hint bits. If Kevin doesn't like the resultant I/O load then he
should use the vacuum_cost_delay parameters to dial down vacuum speed.
regards, tom lane
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: tgl@sss.pgh.pa.us, mr-russ@pws.com.au, simon@2ndquadrant.com, Kevin.Grittner@wicourts.gov
Subject: Re: Heavy write activity on first vacuum of fresh TOAST data
In-Reply-To: <29185.1197618162@sss.pgh.pa.us>
* 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