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
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 |