Re: removing PD_ALL_VISIBLE
От | Robert Haas |
---|---|
Тема | Re: removing PD_ALL_VISIBLE |
Дата | |
Msg-id | CA+TgmoYt=Y1G+d4Nbbmo1PM6XLL2NM5Y598WavknM=zTSxdScQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: removing PD_ALL_VISIBLE (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Fri, May 31, 2013 at 1:44 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, May 31, 2013 at 10:28:12AM -0700, Josh Berkus wrote: >> >> Isn't the visibility map already required for proper return results as >> >> we use it for index-only scans. I think the optimization-only ship has >> >> sailed. >> > >> > At the moment we can remove it without causing corruption. If we were to >> > use it for freezing we couldn't anymore. So there's a difference - how >> > big it is I am not sure. >> >> Depends on your definition of corruption, really. >> >> But yes, right now, the vismap can lose bits without causing any >> corruption, and making all-frozen depend on it would eliminate that. > > Roberts statement was: > >> Loss or corruption of a single visibility map page means possible loss >> of half a gigabyte of data. > > Certainly unidentified corruption of a visibility map page could easily > cause incorrect results. So, technically, _adding_ bits would cause > corruption. Adding bits could cause tuples that ought to be invisible to be treated as visible. Currently, removing bits is harmless (except to performance), but if we used the VM bit to indicate whether the page was frozen in lieu of actually freezing it, a cleared bit would potentially cause vacuum to nuke everything on that page. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: