From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Visibility map, partial vacuums
Date: Thu, 27 Nov 2008 21:44:15 +0200
Message-ID: <492EF88F.9050709@enterprisedb.com> (raw)
In-Reply-To: <5856.1227705135@sss.pgh.pa.us>
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>
Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 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.
Here's an updated version, with a lot of smaller cleanups, and using
relcache invalidation to notify other backends when the visibility map
fork is extended. I already committed the change to FSM to do the same.
I'm feeling quite satisfied to commit this patch early next week.
I modified the VACUUM VERBOSE output slightly, to print the number of
pages scanned. The added part emphasized below:
postgres=# vacuum verbose foo;
INFO: vacuuming "public.foo"
INFO: "foo": removed 230 row versions in 10 pages
INFO: "foo": found 230 removable, 10 nonremovable row versions in *10
out of* 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
That seems OK to me, but maybe others have an opinion on that?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
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-hackers@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, tgl@sss.pgh.pa.us
Subject: Re: Visibility map, partial vacuums
In-Reply-To: <492EF88F.9050709@enterprisedb.com>
* 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