On Tue, 2010-06-08 at 16:58 -0400, Robert Haas wrote: > On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote: > >> Jan Wieck <janwi...@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.
Hmmm: You suggested a variant of this idea, so whatever reasoning was behind your suggestion would be shared here, surely? Tom has been saying we cannot freeze early because we need to keep xmins. I agree with that. This suggestion shows it is possible to freeze a tuple AND keep its xmin. So that removes the argument that we should freeze more aggressively (whenever we write the block) and can thus reduce longer term I/O costs. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
