Re: crash-safe visibility map, take three
| От | Jim Nasby | 
|---|---|
| Тема | Re: crash-safe visibility map, take three | 
| Дата | |
| Msg-id | 7502A9A8-B5C8-4C82-8843-4AE0F638D207@nasby.net обсуждение исходный текст | 
| Ответ на | Re: crash-safe visibility map, take three (Robert Haas <robertmhaas@gmail.com>) | 
| Ответы | Re: crash-safe visibility map, take three | 
| Список | pgsql-hackers | 
On Jan 5, 2011, at 8:10 PM, Robert Haas wrote: > On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh <jesper@krogh.cc> wrote: >> Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit >> serve? > > If we modify a page on which PD_ALL_VISIBLE isn't set, we don't > attempt to update the visibility map. In theory, this is an important > optimization to reduce contention on the visibility map page, since > there are something like 64K heap pages per visibility map page. In > practice, I'm not sure in what workloads it matters or by how much. What specific locking are you worried about? The page locks themselves? Isn't changing the bit essentially a single instructionoperation? This is sounding like premature optimization... ;) -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: