To: Josh Berkus <josh@agliodbs.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Return of the Solaris vacuum polling problem -- anyone remember
	this?
In-reply-to: <4C6C431B.9010406@agliodbs.com> 
References: <4C69827A.409@agliodbs.com> <19969.1281986537@sss.pgh.pa.us>
	<4C6C2B2B.9060501@agliodbs.com> <8599.1282158010@sss.pgh.pa.us>
	<4C6C2E4A.1010506@agliodbs.com> <8807.1282158479@sss.pgh.pa.us>
	<4C6C431B.9010406@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
	message dated "Wed, 18 Aug 2010 13:31:23 -0700"
Date: Wed, 18 Aug 2010 17:02:49 -0400
Message-ID: <13390.1282165369@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Josh Berkus <josh@agliodbs.com> writes:
>> Most likely that's the libc implementation of the select()-based sleeps
>> for vacuum_cost_delay.  I'm still suspicious that the writes are eating
>> more cost_delay points than you think.

> Tested that.  It does look like if I increase vacuum_cost_limit to 10000
> and lower vacuum_cost_page_dirty to 10, it reads 5-7 pages and writes
> 2-3 before each pollsys.  The math seems completely wrong on that,
> though -- it should be 50 and 30 pages, or similar.

I think there could be a lot of cost_delay points getting expended
without any effects visible at the level of strace.  Maybe try fooling
with vacuum_cost_page_hit and vacuum_cost_page_miss, too.

			regards, tom lane