Re: limiting hint bit I/O

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: limiting hint bit I/O
Date: 2011-01-19 13:56:41
Message-ID: AANLkTim4zHct+rn91Mk0mLfSJztR4e3XMVz0xtHjhOGG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> a few weeks back I hacked an experimental patch that removed the hint
>>> bit action completely.  the results were very premature and/or
>>> incorrect, but my initial findings suggested that hint bits might not
>>> be worth the cost from performance standpoint.  i'd like to see some
>>> more investigation in this direction before going with a complex
>>> application mechanism (although that would be beneficial vs the status
>>> quo).
>>
>> I think it's not very responsible to allege that hint bits aren't
>> providing a benefit without providing the patch that you used and the
>> tests that you ran.  This is a topic that needs careful analysis, and
>> I think that saying "hint bits don't provide a benefit... maybe..."
>> doesn't do anything but confuse the issue.  How about doing some tests
>> with the patch from my OP and posting the results?  If removing hint
>> bits entirely doesn't degrade performance, then surely the
>> less-drastic approach I've taken here ought to be OK too.  But in my
>> testing, it didn't look too good.
>
> hm. well, I would have to agree on the performance hit -- I figure 5%
> scan penalty should be about the maximum you'd want to pay to get the
> i/o reduction.  Odds are you're correct and I blew something...I'd be
> happy to test your patch.

Ah, I tested your patch vs stock postgres vs my patch, basically your
results are unhappily correct (mine was just a hair faster than yours
which you'd expect). The differential was even wider on my laptop
class hardware, maybe 26%. I also agree that even if the penalty was
reduced or determined to be worth it anyways, your approach to move
the setting/i/o around to appropriate places is the way to go vs
wholesale removal, unless some way is found to reduce clog lookup
penalty to a fraction of what it is now (not likely, I didn't profile
but I bet a lot of the problem is the lw lock). Interesting I didn't
notice this on my original test :(.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joachim Wieland 2011-01-19 14:01:46 Re: pg_dump directory archive format / parallel pg_dump
Previous Message Simon Riggs 2011-01-19 13:29:46 Re: [COMMITTERS] pgsql: Log replication connections only when log_connections is on