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