Re: Turning off HOT/Cleanup sometimes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Turning off HOT/Cleanup sometimes
Date: 2015-04-15 12:04:46
Message-ID: CA+Tgmobfw8kc+YNXevr45msFZPyc6xJS=KsmX3Awz-mSXQXLCA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 15, 2015 at 3:37 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 14 April 2015 at 21:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Peter commented previously that README.HOT should get an update. The
>> relevant section seems to be "When can/should we prune or
>> defragment?".
>
> That's easy enough to change once we agree to commit.
>
>> I wonder if it would be a useful heuristic to still prune pages if
>> those pages are already dirty.
>
> Useful for who? This is about responsibility. Why should someone
> performing a large SELECT take the responsibility for cleaning pages?

Because it makes it subsequent accesses to the page cheaper. Of
course, that applies in all cases, but when the page is already dirty,
the cost of pruning it is probably quite small - we're going to have
to write the page anyway, and pruning it before it gets evicted
(perhaps even by our scan) will be cheaper than writing it now and
writing it again after it's pruned. When the page is clean, the cost
of pruning is significantly higher.

I won't take responsibility for paying my neighbor's tax bill, but I
might take responsibility for picking up his mail while he's on
holiday.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-04-15 12:07:43 TAP tests of pg_rewind not stopping servers used for the tests
Previous Message Peter Eisentraut 2015-04-15 10:54:21 Re: [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/