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-26 13:32:32 |
Message-ID: | 492D4FF0.2000606@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-11-26 13:40:25 | Re: Simple postgresql.conf wizard |
Previous Message | Tom Lane | 2008-11-26 13:28:04 | Re: Brittleness in regression test setup |