Re: Savepoints in transactions for speed?
| От | Mike Blackwell |
|---|---|
| Тема | Re: Savepoints in transactions for speed? |
| Дата | |
| Msg-id | CANPAkgutXZHmkPQ0ungdFixT6Nqc88c9cE=yNiwHPNag+JUHEA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Savepoints in transactions for speed? (Jeff Janes <jeff.janes@gmail.com>) |
| Ответы |
Re: Savepoints in transactions for speed?
|
| Список | pgsql-performance |
On Thu, Nov 29, 2012 at 12:09 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
Hmm.... From the 9.2 manual it seems that might not work out so well:
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.
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.
В списке pgsql-performance по дате отправления: