Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
