Skip site navigation (1) Skip section navigation (2)

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

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Date: 2008-03-10 12:16:27
Message-ID: 47D5269B.8060103@postnewspapers.com.au (view raw or flat)
Thread:
Lists: pgsql-patchespgsql-performance
Heikki Linnakangas wrote:
> You must be having an exception handler block in that pl/pgsql 
> function, which implicitly creates a new subtransaction on each 
> invocation of the exception handler block, so you end up with hundreds 
> of thousands of committed subtransactions.
I've just confirmed that that was indeed the issue, and coding around 
the begin block dramatically cuts the runtimes of commands executed 
after the big import function.

Thanks again!

--
Craig Ringer

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2008-03-10 14:33:58
Subject: Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Previous:From: Craig RingerDate: 2008-03-10 11:29:01
Subject: Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

pgsql-patches by date

Next:From: Andrew DunstanDate: 2008-03-10 12:24:08
Subject: Re: Include Lists for Text Search
Previous:From: Craig RingerDate: 2008-03-10 11:29:01
Subject: Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group