Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit - Mailing list pgsql-patches

From Heikki Linnakangas
Subject Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Date
Msg-id 47D813FB.1000006@enterprisedb.com
Whole thread Raw
In response to Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
List pgsql-patches
Pavan Deolasee wrote:
> Wait. Subtransaction ids are local to a transaction and always start from 1.
> See this:
>
>     /*
>      * reinitialize within-transaction counters
>      */
>     s->subTransactionId = TopSubTransactionId;
>     currentSubTransactionId = TopSubTransactionId;

No, we're not talking about SubTransactionIds. We're talking about real
XIDs assigned to subtransactions. Subtransactions are assigned regular
XIDs as well, just like top-level transactions.

I can see where you were coming from with you suggestion now :-).

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Next
From: "Pavan Deolasee"
Date:
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit