Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
