Re: bitmaps and correlation
От | Heikki Linnakangas |
---|---|
Тема | Re: bitmaps and correlation |
Дата | |
Msg-id | f6afd7af-4ee2-923f-ba16-2bd2810f3cbe@iki.fi обсуждение исходный текст |
Ответ на | Re: bitmaps and correlation (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: bitmaps and correlation
|
Список | 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 по дате отправления: