Fix gin index cost estimation

From: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Fix gin index cost estimation
Date: 2022-08-03 07:26:32
Message-ID: 3188617.44csPzL39Z@aivenronan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

Following the bug report at [1], I sent the attached patch to pgsql-bugs
mailing list. I'm starting a thread here to add it to the next commitfest.

The problem I'm trying to solve is that, contrary to btree, gist and sp-gist
indexes, gin indexes do not charge any cpu-cost for descending the entry tree.

This can be a problem in cases where the io cost is very low. This can happen
with manual tuning of course, but more surprisingly when the the IO cost is
amortized over a large number of iterations in a nested loop. In that case, we
basically consider it free since everything should already be in the shared
buffers. This leads to some inefficient plans, as an equivalent btree index
should be picked instead.

This has been discovered in PG14, as this release makes it possible to use a
pg_trgm gin index with the equality operator. Before that, only the btree
would have been considered and as such the discrepancy in the way we charge
cpu cost didn't have noticeable effects. However, I suspect users of btree_gin
could have the same kind of problems in prior versions.

Best regards,

[1]: https://www.postgresql.org/message-id/flat/
2187702.iZASKD2KPV%40aivenronan#0c2498c6a85e31a589b3e9a6a3616c52

--
Ronan Dunklau

Attachment Content-Type Size
v1-0001-Fix-gin-costing.patch text/x-patch 2.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2022-08-03 07:28:47 Re: Race between KeepFileRestoredFromArchive() and restartpoint
Previous Message Noah Misch 2022-08-03 07:16:17 Re: remove more archiving overhead