On Thu, Nov 29, 2012 at 10:14 AM, Mike Blackwell <mike.blackw...@rrd.com> wrote: > > > > On Thu, Nov 29, 2012 at 12:09 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> >> >> But If you do keep the drop index inside the transaction, then you >> would probably be better off using truncate rather than delete, and >> rebuild the index non-concurrently and move that inside the >> transaction as well. >> > > > Hmm.... From the 9.2 manual it seems that might not work out so well: > > TRUNCATE is not MVCC-safe (see Chapter 13 for general information about > MVCC). After truncation, the table will appear empty to all concurrent > transactions, even if they are using a snapshot taken before the truncation > occurred. > > It looks like other transactions could find an empty table while it was > being reloaded under that approach.
They would block during the load, it is just after the load that they would see the table as empty. I thought that that would only be a problem for repeatable read or higher, but a test shows that read committed has that problem as well. But yeah, that could definitely be a problem with that method. Cheers, Jeff -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
