On 10/7/25 16:35, Andres Freund wrote:
> Hi,
>
> On 2025-10-07 14:08:27 +0200, Tomas Vondra wrote:
>> On 10/7/25 01:56, Andres Freund wrote:
>>> A correlated index scan today will not do IO combining, despite being
>>> accounted as seq_page_cost. So just doing individual 8kB IOs actually seems to
>>> be the appropriate comparison. Even with table fetches in index scans doing
>>> IO combining as part by your work, the reads of the index data itself won't be
>>> combined. And I'm sure other things won't be either.
>>>
>>
>> But that's the point. If the sequential reads do I/O combining and index
>> scans don't (and I don't think that will change anytime soon), then that
>> makes sequential I/O much more efficient / cheaper. And we better
>> reflect that in the cost somehow. Maybe increasing the random_page_cost
>> is not the right/best solution? That's possible.
>
> The table fetch portion of an index scan uses seq_page_cost too, with the
> degree of it being used determined by the correlation (c.f. cost_index()).
> Given that we use random page cost and sequential page cost both for index
> scan and non-index scan related costs, I just don't see how it can make sense
> to include index related overheads in random_page_cost but not seq_page_cost.
>
I'm not against separating the cost into some (new?) GUC cost parameter,
not into random_page_cost. At this point that's all we have, so that's
what my testing relies on. But you're probably right we may need more
nuance in the costing.
regards
--
Tomas Vondra
