Re: HOT is applied

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;