Re: HOT is applied

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HOT is applied
Date: 2007-09-21 08:04:14
Message-ID: 200709210804.l8L84E927549@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> 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.)

This might be a simplistic question but if the page is +90% full and
there is a long-lived transaction, isn't Postgres going to try pruning
on each page read access?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gokulakannan Somsundaram 2007-09-21 08:05:31 Re: Improving the Performance of Full Table Updates
Previous Message Eswar 2007-09-21 05:42:36 Query