On Fri, May 24, 2013 at 11:52 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> The basic problem is that if the data is going to be removed before it
>> would have gotten frozen, then the extra FPIs are just overhead. In
>> effect, we're just deciding to freeze a lot sooner.
>
> Well, freezing without removing information for debugging.
Sure, but what I'm trying to avoid is incurring the WAL cost of
freezing. If we didn't mind paying that sooner, we could just drop
vacuum_freeze_min/table_age. But we do mind that.
>> And while that
>> might well be beneficial in some use cases (e.g. the data's already in
>> cache) it might also not be so beneficial (the table is larger than
>> cache and would have been dropped before freezing kicked in).
>
> Not sure how caching comes into play here? At this point we know the
> page to be in cache already since vacuum is looking at it anyway?
OK, true.
> I think it's not really comparable since in those situations we a)
> already do an XLogInsert(). b) already dirty the page. so the only
> change is that we possibly write an additionall full page image. If
> there is actually near future DML write activity that would make the
> all-visible superflous that would have to FPI likely anyway.
Well, if there's near-future write activity, then freezing is pretty
worthless anyway. What I'm trying to avoid is adding WAL overhead in
the case where there *isnt* any near-future write activity, like
inserting 100MB of data into an existing table.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
