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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
