Re: Freeze avoidance of very large table.

On 23/04/15 17:45, Bruce Momjian wrote:
> On Thu, Apr 23, 2015 at 09:45:38AM -0400, Robert Haas wrote:
>>> Right.  My point is that either you do X 2M times to maintain that fork
>>> and the overhead of the file existence, or you do one VACUUM FREEZE.  I
>>> am saying that 2M is a large number and adding all those X's might
>>> exceed the cost of a VACUUM FREEZE.
>>
>> I agree, but if we instead make this part of the visibility map
>> instead of a separate fork, the cost is much less.  It won't be any
>> more expensive to clear 2 consecutive bits any time a page is touched
>> than it is to clear 1.  The VM fork will be twice as large, but still
>> tiny.  And the fact that you'll have only half as many pages mapping
>> to the same VM page may even improve performance in some cases by
>> reducing contention.  Even when it reduces performance, I think the
>> impact will be so tiny as not to be worth caring about.
>
> Agreed, no extra file, and the same write volume as currently.  It would
> also match pg_clog, which uses two bits per transaction --- maybe we can
> reuse some of that code.
>

Yeah, this approach seems promising. We probably can't reuse code from 
clog because the usage pattern is different (key for clog is xid, while 
for visibility/freeze map ctid is used). But visibility map storage 
layer is pretty simple so it should be easy to extend it for this use.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services