On Thu, Nov 29, 2012 at 10:14 AM, Mike Blackwell <mike.blackwell@xxxxxxx> wrote: > > > > On Thu, Nov 29, 2012 at 12:09 PM, Jeff Janes <jeff.janes@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
