Re: bitmaps and correlation - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: bitmaps and correlation
Date
Msg-id f6afd7af-4ee2-923f-ba16-2bd2810f3cbe@iki.fi
Whole thread Raw
In response to Re: bitmaps and correlation  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: bitmaps and correlation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 06/11/2020 19:57, Justin Pryzby wrote:
> On Fri, Nov 06, 2020 at 01:51:26PM +0000, Anastasia Lubennikova wrote:
>> The first patch is simply a refactoring and don't see any possible objections against it.
>> The second patch also looks fine to me. The logic is understandable and the code is neat.

+1

>> It wouldn't hurt to add a comment for this computation, though.
>> +    pages_fetched = pages_fetchedMAX + indexCorrelation*indexCorrelation*(pages_fetchedMIN - pages_fetchedMAX);
> 
> You're right.  It's like this:
> // interpolate between c==0: pages_fetched=max and c==1: pages_fetched=min
> pages_fetched = min + (max-min)*(1-c**2)
> pages_fetched = min + max*(1-c**2) - min*(1-c**2)
> pages_fetched = max*(1-c**2) + min - min*(1-c**2)
> pages_fetched = max*(1-c**2) + min*(c**2)
> pages_fetched = max - max*c**2 + min*(c**2)
> pages_fetched = max + min*(c**2) - max*c**2
> pages_fetched = max + c**2 * (min-max)
> 
> I'm not sure if there's a reason why it's written like that, but (min-max)
> looks odd, so I wrote it like:
> pages_fetched = max - c**2 * (max-min)

I agree min-max looks odd. max - c**2 * (max-min) looks a bit odd too, 
though. Whatever we do here, though, I'd suggest that we keep it 
consistent with cost_index().

Other than that, and a quick pgdindent run, this seems ready to me. I'll 
mark it as Ready for Committer.

- Heikki



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: configure and DocBook XML
Next
From: Paul Förster
Date:
Subject: Re: configure and DocBook XML