Re: limiting hint bit I/O - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: limiting hint bit I/O
Date
Msg-id AANLkTim4zHct+rn91Mk0mLfSJztR4e3XMVz0xtHjhOGG@mail.gmail.com
Whole thread Raw
In response to Re: limiting hint bit I/O  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: limiting hint bit I/O  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: limiting hint bit I/O  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure <mmoncure@gmail.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Log replication connections only when log_connections is on
Next
From: Joachim Wieland
Date:
Subject: Re: pg_dump directory archive format / parallel pg_dump