Ronan Dunklau <ronan.dunklau@aiven.io> writes:
> Looking into it, it looks like we are not charging a cpu "descent" cost for
> the entry tree of the gin index, which we do for the btree index. In general,
> it does not pose a problem since IO costs are far greater than cpu costs. But
> when the index scan is inside a nestloop, we account for cache effect and
> amortize the cost of IO over the number of outer scans, which reduces its
> relative importance significantly. In that case, the index scan on the gin
> index appears much cheaper, as the constant cpu cost is not taken into
> account.
Hm, so it'd seem this probably could happen when comparing *any*
non-btree index to a btree index, because I don't think we are
particularly careful with CPU cost estimation for any of the
other index types. If we do something about this, we probably
have to look at all of them.
regards, tom lane
