Re: Idea for getting rid of VACUUM FREEZE on cold pages
От | Robert Haas |
---|---|
Тема | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Дата | |
Msg-id | AANLkTikYI4Q1tC_lvleBTna5q9Tjw4C0M2c_gUjdGZzi@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Idea for getting rid of VACUUM FREEZE on cold pages (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Idea for getting rid of VACUUM FREEZE on cold pages
|
Список | pgsql-hackers |
On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote: >> Jan Wieck <JanWieck@Yahoo.com> writes: >> > On 6/2/2010 3:10 PM, Alvaro Herrera wrote: >> >> I'd prefer a setting that would tell the system to freeze all tuples >> >> that fall within a safety range whenever any tuple in the page is frozen >> >> -- weren't you working on a patch to do this? (was it Jeff Davis?) >> >> > I just see a lot of cost caused by this "safety range". I yet have to >> > see its real value, other than "feel good". >> >> Jan, you don't know what you're talking about. I have repeatedly had >> cases where being able to look at xmin was critical to understanding >> a bug. I *will not* hold still for a solution that effectively reduces >> min_freeze_age to zero. > > Recent history shows Tom's view to be the most useful one: its useful to > keep seeing the xmin. The last time we altered the way we set hint bits > we caused multiple data loss bugs doing it. We will need to debug things > and the WAL is always long gone (great idea though). > > Why not just have a separate flag for HEAP_XMIN_FROZEN, that way we can > keep the xmin but also can see it is frozen? We could do that, but I think the point of this exercise is to reduce I/O - specifically, I/O caused by anti-wraparound vacuums - and I'm not clear how such a flag would help with that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: