Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
Jeff Davis pg...@j-davis.com wrote: There are two ways to do the threshold: 1. Constant fraction of vacuum_freeze_min_age 2. Extra GUC I appreciate that there may be room to improve this while protecting the forensic values; but there are already strategies for managing the day-to-day performance issues as long as you have adequate backup to not need to rely on old XID information for recovery. What we don't have covered is loading a database from pg_dump without having to rewrite all pages at least once afterward -- and likely two more times, with most maintenance strategies. I seem to remember that someone took a shot at making a special case of WAL-bypassed inserts, but there was a problem or two that were hard to overcome. Does anyone recall the details? Was that about pre-setting the hint bits for a successful commit (based on the fact that the entire table will be empty if rolled back and no data will be visible to any other transaction until commit), or was it about setting the frozen XID in the inserted tuples (based on the fact that this is no less useful for forensic purposes than having all rows set to any other value)? Should we have a TODO item for this special case, or is it not wanted or viewed as having intractable problems? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[PERFORM] Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
Alvaro Herrera alvhe...@commandprompt.com wrote: Jeff Davis wrote: Why aren't we more opportunistic about freezing tuples? For instance, if we already have a dirty buffer in cache, we should be more aggressive about freezing those tuples than freezing tuples on disk. The most widely cited reason is that you lose forensics data. Although they are increasingly rare, there are still situations in which the heap tuple machinery messes up and the xmin/xmax/etc fields of the tuple are the best/only way to find out what happened and thus fix the bug. If you freeze early, there's just no way to know. Although I find it hard to believe that this is compelling argument in the case where an entire table or database is loaded in a single database transaction. In the more general case, I'm not sure why this argument applies here but not to cassert and other diagnostic options. It wouldn't surprise me to find workloads where writing data three times (once for the data, once for hint bits, and once to freeze the tid) affects performance more than cassert. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PERFORM] Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
On Thu, 2009-08-13 at 17:17 -0500, Kevin Grittner wrote: It wouldn't surprise me to find workloads where writing data three times (once for the data, once for hint bits, and once to freeze the tid) I'm not sure that we're limited to 3 times, here. I could be missing something, but if you have tuples with different xmins on the same page, some might be older than 100M, which you freeze, and then you will have to come back later to freeze the rest. As far as I can tell, the maximum number of writes is the number of tuples that fit on the page. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
