Re: should we set hint bits without dirtying the page?

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: should we set hint bits without dirtying the page?
Date: 2010-12-03 06:18:57
Message-ID: 4CF88BD1.9080506@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.12.2010 04:54, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>> I then got to wondering whether we should even go a step further, and
>> simply decree that a page with only hint bit updates is not dirty and
>> won't be written, period.
>
> This sort of thing has been discussed before. It seems fairly clear to
> me that any of these variations represents a performance tradeoff: some
> cases will get better and some will get worse. I think we are not going
> to get far unless we can agree on a set of benchmark cases that we'll
> use to decide whether the tradeoff is a win or not. How can we arrive
> at that?

It's pretty easy to come up with a test case where that would be a win.
I'd like to see some benchmark results of the worst case, to see how
much loss we're talking about at most. Robert described the worst case:

> Where it's a problem is
> when you have a huge table that you're scanning over and over again,
> especially if data in that table was loaded by many different, widely
> spaced XIDs that require looking at many different CLOG pages.

I'd like to add to that: "and the table is big enough to not fit in
shared_buffers, but small enough to fit in OS cache".

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2010-12-03 07:13:38 Re: pg_execute_from_file review
Previous Message Itagaki Takahiro 2010-12-03 05:01:23 Re: Author names in source files