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

From Tom Lane
Subject Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Date
Msg-id 24304.1205162440@sss.pgh.pa.us
Whole thread Raw
In response to Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-performance
"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> The oprofile output is pretty damning:

> samples  %        symbol name
> 42148    99.7468  TransactionIdIsCurrentTransactionId

Oh, I have no doubt that that could eat a lot of cycles inside the
originating transaction ;-).  I just misread Craig's complaint as
being about the cost of the first table scan *after* that transaction.

Getting rid of the linked-list representation would be a win in a couple
of ways --- we'd not need the bogus "list of XIDs" support in pg_list.h,
and xactGetCommittedChildren would go away.  OTOH AtSubCommit_childXids
would get more expensive.

            regards, tom lane

pgsql-performance by date:

Previous
From: Gregory Stark
Date:
Subject: Re: count * performance issue
Next
From: Dimitri Fontaine
Date:
Subject: Re: multi-threaded pgloader needs your tests