Tom Lane wrote: > I've committed the HOT patch. Thanks, much easier to work with it now that it's in.
> I'd still like to think about whether we > can be smarter about when to invoke pruning, but that's a small enough > issue that the patch can go in without it. Yeah. I'm doing some micro-benchmarking, and the attached test case is much slower with HOT. It's spending a lot of time trying to prune, only to find out that it can't. Instead of/in addition to avoiding pruning when it doesn't help, maybe we could make HeapTupleSatisfiesVacuum cheaper. I'm going to continue testing, this is just a heads-up that HOT as committed seriously hurts performance in some cases. (though one can argue that this test case isn't a very realistic one.) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
DROP TABLE IF EXISTS testtable; CREATE TABLE testtable (key integer); -- Note that there's no indexes, so updates have to do a seq scan. CREATE OR REPLACE FUNCTION testfunc(data int, key1 int) RETURNS int AS $$ DECLARE BEGIN FOR cnt IN 1..10000 LOOP UPDATE testtable SET key = data WHERE key = key1; END LOOP; RETURN 1; END; $$ LANGUAGE plpgsql; INSERT INTO testtable VALUES (1); BEGIN; SELECT testfunc(1,1); COMMIT;
---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org