Re: should we set hint bits without dirtying the page?
От | Josh Berkus |
---|---|
Тема | Re: should we set hint bits without dirtying the page? |
Дата | |
Msg-id | 4CF83778.9030400@agliodbs.com обсуждение исходный текст |
Ответ на | should we set hint bits without dirtying the page? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: should we set hint bits without dirtying the page?
|
Список | pgsql-hackers |
On 12/2/10 4:00 PM, Robert Haas wrote: > As soon as all tuples on the page are all-visible, VACUUM will freeze > every tuple on the page (setting a HEAP_XMIN_FROZEN bit rather than > actually overwriting XMIN, to preserve forensic information) and mark > it all-visible in a single WAL-logged operation. Also, we could have > the background writer (!) try to perform this same operation on pages > evicted during the cleaning scan. This would impose the same sort of > I/O cap as the previous idea, although it would generate not only page > writes but also WAL activity. I would love this. It would also help considerably with the "freezing already cold data" problem ... if we were allowed to treat the frozen bit as canonical and not update any of the tuples. While never needing to touch pages at all for freezing is my preference, updating them while they're in memory anyway is a close second. Hmm. That doesn't work, though; the page can contain tuples which are attached to rolledback XIDs. Also, autovacuum would have no way of knowing which pages are frozen without reading them. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
В списке pgsql-hackers по дате отправления: