Re: limiting hint bit I/O

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: limiting hint bit I/O
Date: 2011-01-14 18:07:55
Message-ID: AANLkTi=h5WVRozEBtYh6Ss3qhqUXpkVCLRBZQS5R=Q5_@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 14, 2011 at 1:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jan 14, 2011 at 12:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Moreover this whole business of not treating hint-bit setting as
>>> a page-dirtying operation is completely experimental/unproven IMO, so it
>>> would be better to keep the patch footprint as small as possible.
>
>> I have some concerns about that proposal, but it might be the right
>> way to go.  Before we get too far off into the weeds, though, let's
>> back up and talk about something more fundamental: this seems to be
>> speeding up the first run by 6x at the expense of slowing down many
>> subsequent runs by 10-15%.  Does that make this whole idea dead on
>> arrival?
>
> Well, it reinforces my opinion that it's experimental ;-).  But "first
> run" of what, exactly?

See the test case in my OP. The "runs" in question are "select sum(1) from s".

> And are you sure you're taking a wholistic view
> of the costs/benefits?

No.

--
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 Robert Haas 2011-01-14 18:08:27 Re: FOR KEY LOCK foreign keys
Previous Message Robert Haas 2011-01-14 18:06:25 Re: limiting hint bit I/O