Re: Do we need so many hint bits?
От | Jeff Davis |
---|---|
Тема | Re: Do we need so many hint bits? |
Дата | |
Msg-id | 1353048263.10198.11.camel@jdavis-laptop обсуждение исходный текст |
Ответ на | Re: Do we need so many hint bits? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, 2012-11-15 at 22:21 -0500, Tom Lane wrote: > We aren't pressed for flag bits particularly. I think the main > attraction of this idea is precisely to reduce unnecessary page dirties, > and so that leads me to suggest a variant: keep the four bits defined as > now, but do not attempt to set XMIN_INVALID or XMAX_COMMITTED unless the > page is already dirty. This would make it a straight-up trade of more > clog consultation for fewer page dirties. Sounds reasonable. > > Also, I am wondering about PD_ALL_VISIBLE. It was originally introduced > > in the visibility map patch, apparently as a way to know when to clear > > the VM bit when doing an update. It was then also used for scans, which > > showed a significant speedup. But I wonder: why not just use the > > visibilitymap directly from those places? > > Added contention for access to the visibility map pages would be a > problem. Can you think of a reasonable (or worst-case) test scenario that would illustrate this problem? Would I need a many-core box to actually test this? Also, what locks do you expect to be contended? The buffer header lock while pinning the VM page? Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: