Re: Improved Cost Calculation for IndexOnlyScan - Mailing list pgsql-hackers

From Hamid Akhtar
Subject Re: Improved Cost Calculation for IndexOnlyScan
Date
Msg-id CANugjhvqizw0K7rm96x9x4f_4N-_P-tzngnX0aGdbFf8-e0PMg@mail.gmail.com
Whole thread Raw
In response to Re: Improved Cost Calculation for IndexOnlyScan  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Improved Cost Calculation for IndexOnlyScan  (Hamid Akhtar <hamid.akhtar@gmail.com>)
List pgsql-hackers


On Tue, Sep 29, 2020 at 2:57 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 29/09/2020 11:49, Hamid Akhtar wrote:
> So, not actually random replacement here, rather a change with
> baserel->allvisfrac taken into consideration (as given below):
> ----
> index_random_page_cost = Min(spc_seq_page_cost + spc_random_page_cost *
> (1.0 - baserel->allvisfrac), spc_random_page_cost);
> ----
>
> Does this make sense?

No. genericcostestimate() is only concerned with accesses to the index,
not the the heap accesses that are needed with Index Scans. 'allvisfrac'
should not affect the number of *index* pages fetched in any way.

- Heikki

Currently, the costing for indexonlyscan only differs based on 'allvisfrac'. IIUC, the current implementation changes the number of pages being fetched based on 'allvisfrac'.

This patch actually makes indexonlyscan specific changes to genericcostestimate function. Currently, regardless of the value of 'allvisfrac', it is being assumed that the cost of fetching index pages is random page cost. That is not aligned with the current cost calculation for indexonlyscan. Therefore, I'm suggesting to reduce the random page in a similar fashion in case of indexonlyscan.

I'm adding this to the commitfest.

--
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
ADDR: 10318 WHALLEY BLVD, Surrey, BC
CELL:+923335449950  EMAIL: mailto:hamid.akhtar@highgo.ca
SKYPE: engineeredvirus

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Next
From: Andrey Borodin
Date:
Subject: Re: Deleting older versions in unique indexes to avoid page splits