Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 8000C65014C for ; Wed, 26 Nov 2008 09:32:41 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 47709-08 for ; Wed, 26 Nov 2008 09:32:38 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mail.postgresql.org (Postfix) with ESMTP id 66DF065008C for ; Wed, 26 Nov 2008 09:32:38 -0400 (AST) Received: by nf-out-0910.google.com with SMTP id c7so252428nfi.23 for ; Wed, 26 Nov 2008 05:32:36 -0800 (PST) Received: by 10.210.45.17 with SMTP id s17mr6001388ebs.65.1227706356289; Wed, 26 Nov 2008 05:32:36 -0800 (PST) Received: from ?80.222.79.63? (dsl-hkibrasgw2-fe4fde00-63.dhcp.inet.fi [80.222.79.63]) by mx.google.com with ESMTPS id h6sm803079nfh.21.2008.11.26.05.32.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Nov 2008 05:32:35 -0800 (PST) Message-ID: <492D4FF0.2000606@enterprisedb.com> Date: Wed, 26 Nov 2008 15:32:32 +0200 Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Tom Lane CC: PostgreSQL-development Subject: Re: Visibility map, partial vacuums References: <4905AE17.7090305@enterprisedb.com> <491D376B.9000608@enterprisedb.com> <491D7F52.6070908@enterprisedb.com> <4925664C.3090605@enterprisedb.com> <26361.1227467112@sss.pgh.pa.us> <492A6032.6080000@enterprisedb.com> <18086.1227537479@sss.pgh.pa.us> <492D4460.1000809@enterprisedb.com> <5856.1227705135@sss.pgh.pa.us> In-Reply-To: <5856.1227705135@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Heikki Linnakangas X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200811/1726 X-Sequence-Number: 128438 Tom Lane wrote: > Heikki Linnakangas writes: >> There is another problem, though, if the map is frequently probed for >> pages that don't exist in the map, or the map doesn't exist at all. >> Currently, the size of the map file is kept in relcache, in the >> rd_vm_nblocks_cache variable. Whenever a page is accessed that's > >> rd_vm_nblocks_cache, smgrnblocks is called to see if the page exists, >> and rd_vm_nblocks_cache is updated. That means that every probe to a >> non-existing page causes an lseek(), which isn't free. > > Well, considering how seldom new pages will be added to the visibility > map, it seems to me we could afford to send out a relcache inval event > when that happens. Then rd_vm_nblocks_cache could be treated as > trustworthy. > > Maybe it'd be worth doing that for the FSM too. The frequency of > invals would be higher, but then again the reference frequency is > probably higher too? A relcache invalidation sounds awfully heavy-weight. Perhaps a light-weight invalidation event that doesn't flush the entry altogether, but just resets the cached sizes? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com