Re: Turning off HOT/Cleanup sometimes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Turning off HOT/Cleanup sometimes
Date: 2014-01-09 21:43:54
Message-ID: 18329.1389303834@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> The problem with saying that we should let VACUUM do this work is the
> same as the problem with saying that if you're late for your Concorde
> flight, you should go running across the tarmac and try to catch it.
> The cost of dead tuples is related in a linear fashion to the rate at
> which pages are accessed. Not coincidentally, the number of
> opportunities for HOT pruning is *also* related in a linear fashion to
> the rate at which pages are accessed. This is why it works so well.

That seems like a large oversimplification. Some (most?) of the costs of
dead tuples are proportional to the rate of dead tuple creation. I grant
that there are also some costs proportional to the rate at which scans
visit dead tuples, but I really don't believe that the latter are
dominant. So I think it's bogus to claim that the current behavior is
somehow optimal.

One more time: the sole reason it works the way it does now is that that
was the path of least resistance back in 2007, and we never yet got around
to trying to optimize that. I'm glad to see someone wanting to revisit
the issue, but I don't think that we necessarily have to go as far as
creating user-visible knobs in order to make it better.

> The rate at which vacuuming happens does not ramp up in the same way;
> it's limited by autovacuum cost settings (which people tend not have
> set correctly, and don't adjust themselves on the fly)

True, but that seems like a pretty well-defined improvement project right
there (as well as an argument against user-visible knobs in general ;-)).
Nasby's speculations just upthread could be useful here, too.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-01-09 22:08:24 Re: nested hstore patch
Previous Message Steeve Lennmark 2014-01-09 21:38:24 Re: [PATCH] Relocation of tablespaces in pg_basebackup