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

Performance regression on CVS head

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Performance regression on CVS head
Date: 2007-06-04 20:36:11
Message-ID: 466477BB.7040907@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
I tried to repeat the DBT-2 runs with the "oldestxmin refresh" patch, 
but to my surprise the baseline run with CVS head, without the patch, 
behaved very differently than it did back in March.

I rerun the a shorter 1h test with CVS head from May 20th, and March 6th 
(which is when I ran the earlier tests), and something has clearly been 
changed between those dates that affects the test. Test run 248 is with 
CVS checkout from May 20th, and 249 is from March 6th:
http://community.enterprisedb.com/oldestxmin/

Vacuum on the stock table is started right after the rampup, and the 
drop in performance happens at the very moment that the vacuum finishes.

Anyone have an explanation for this?

One theory is that after VACUUM has populated the FSM, all updates need 
to do one extra I/O to read in a page with free space to insert to, 
instead of just extending the relation. But I don't think anything has 
changed recently in that area. Another theory is that the VACUUM updates 
some stats, which changes the access plan used to a much worse one. But 
the tables have been analyzed before the test, and again I don't 
remember any changes to that recently.

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

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-06-04 20:59:12
Subject: Re: Implicit casts with generic arrays
Previous:From: Tom LaneDate: 2007-06-04 20:30:35
Subject: Re: Implicit casts with generic arrays

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