Re: COPY FREEZE and PD_ALL_VISIBLE

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY FREEZE and PD_ALL_VISIBLE
Date: 2015-11-03 14:23:28
Message-ID: CAA4eK1L1bCiOjYxWDP7_8+_wUE+BYrQFhYNbAEGXWEJe17n1zQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 23, 2015 at 6:29 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> On 21 October 2015 at 13:31, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
> Index-only scans will visit the heap for each tuple until the first VACUUM
>> is done.
>>
>> The first vacuum will read the entire table, but not need to write it
>> anymore. And will create the _vm file.
>>
>> I think we really want to create _vm file as well as set PD_ALL_VISIBLE,
>> but I don't know the best way to do that. Set a flag somewhere and then
>> create it in bulk at the end of the transaction? Set it bit by bit as the
>> pages are extended and initialized?
>>
>
> Easy enough to do it at the end of the COPY FREEZE in one step.
>

Here, we might want to consider that setting bit in visibility map
will generate WAL log whereas Copy Freeze otherwise skip WAL
when wal_level is less than archive. This can lead to extra disk
writes which can slow down Copy Freeze, but OTOH that might
be acceptable.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2015-11-03 14:23:54 Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Previous Message Robert Haas 2015-11-03 14:11:04 Re: [patch] to build docs on Mac OS X El Capitan with MacPorts