Re: Visibility map, partial vacuums
От | Simon Riggs |
---|---|
Тема | Re: Visibility map, partial vacuums |
Дата | |
Msg-id | 1225203735.3971.167.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Visibility map, partial vacuums (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Visibility map, partial vacuums
|
Список | pgsql-hackers |
On Tue, 2008-10-28 at 14:57 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote: > >> One option would be to just ignore that problem for now, and not > >> WAL-log. > > > > Probably worth skipping for now, since it will cause patch conflicts if > > you do. Are there any other interactions with Hot Standby? > > > > But it seems like we can sneak in an extra flag on a HEAP2_CLEAN record > > to say "page is now all visible", without too much work. > > Hmm. Even if a tuple is visible to everyone on the master, it's not > necessarily yet visible to all the read-only transactions in the slave. Never a problem. No query can ever see the rows removed by a cleanup record, enforced by the recovery system. > > Does the PD_ALL_VISIBLE flag need to be set at the same time as updating > > the VM? Surely heapgetpage() could do a ConditionalLockBuffer exclusive > > to set the block flag (unlogged), but just not update VM. Separating the > > two concepts should allow the visibility check speed gain to more > > generally available. > > Yes, that should be possible in theory. There's no version of > ConditionalLockBuffer() for conditionally upgrading a shared lock to > exclusive, but it should be possible in theory. I'm not sure if it would > be safe to set the PD_ALL_VISIBLE_FLAG while holding just a shared lock, > though. If it is, then we could do just that. To be honest, I'm more excited about your perf results for that than I am about speeding up some VACUUMs. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: