Skip site navigation (1) Skip section navigation (2)

Re: Visibility map, partial vacuums

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Visibility map, partial vacuums
Date: 2008-11-27 19:44:15
Message-ID: 492EF88F.9050709@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-11-27 19:45:34
Subject: Re: Distinct types
Previous:From: Simon RiggsDate: 2008-11-27 19:38:23
Subject: Re: blatantly a bug in the documentation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group