Re: Visibility map, partial vacuums

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Visibility map, partial vacuums
Дата
Msg-id 5856.1227705135@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Visibility map, partial vacuums  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Visibility map, partial vacuums  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Visibility map, partial vacuums  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
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.

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?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Rob Kirkbride"
Дата:
Сообщение: Re: Enhancement to pg_dump
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Brittleness in regression test setup