Amit Gupta writes:
>> Moreover it only models a single index scan. It assumes nothing is cached
>> prior to the index scan which is very much not true if we're repeatedly
>> scanning similar ranges of keys.
>>
>
> It's reasonable to assume that nothing is cached for estimating the cost.
Not re
Amit Gupta writes:
> While trying to figure out an appropriate cost expression function for
> Thick indexes, i learned that we are using Mackert and Lohman formula
> (described in their paper "Index Scans Using a Finite LRU Buffer: A
> Validated I/O Model", ACM Transactions on Database Systems).
Amit Gupta writes:
> Upon taking a cursory look at the cost functions of other operators, I
> realized that available memory (effective_cache_size) is not
> considered for estimating the costs of hash/sort/NLjoin/etc. Why is
> that the case?
The relevant number for those is work_mem not effective
While trying to figure out an appropriate cost expression function for
Thick indexes, i learned that we are using Mackert and Lohman formula
(described in their paper "Index Scans Using a Finite LRU Buffer: A
Validated I/O Model", ACM Transactions on Database Systems).
The paper's result is as foll
