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

Re: Not HOT enough

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Not HOT enough
Date: 2011-11-23 18:15:58
Message-ID: 507.1322072158@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Wed, Nov 23, 2011 at 5:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>>> Normal catalog access does not use HOT and never has.

>> You are mistaken.

> Normal catalog access against shared catalogs via heap_scan does not
> use HOT cleanup, because it uses SnapshotNow.

Not sure what you are basing these statements on.  Normal catalog access
typically goes through indexam.c, which AFAICS will call
heap_page_prune_opt on every heap page it visits, quite independently
of what snapshot is used.  There are no cases I know of where the system
prefers heapscans on catalogs, except possibly pg_am which is known to
be small.

> However, since we're talking about these tables only
> ...
> then I think it's fair to say that they are seldom updated/deleted and
> so the effect of HOT cleanup is not important for those tables.

I agree with Alvaro that pg_shdepend is probably a bit too volatile
to make such an assumption safe.

> The real question is do we favour HOT cleanup on those small 8 tables,
> or do we favour HOT cleanup of every other table?

No, the real question is why not think a little harder and see if we can
come up with a solution that doesn't involve making some cases worse to
make others better.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-11-23 18:30:18
Subject: Re: Not HOT enough
Previous:From: Simon RiggsDate: 2011-11-23 17:58:25
Subject: Re: Not HOT enough

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