Re: index cost estimation
Ronan Dunklau <ronan.dunklau@aiven.io>
From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org
Cc: Hung Nguyen <hungnq1989@gmail.com>, pgsql-bugs@lists.postgresql.org,
"rjuju123@gmail.com" <rjuju123@gmail.com>,
Ronan Dunklau <ronan.dunklau@aiven.io>
Date: 2022-07-06T15:42:28Z
Lists: pgsql-bugs
Attachments
- v1-0001-Fix-gin-costing.patch (text/x-patch)
Le mercredi 6 juillet 2022, 16:52:09 CEST Ronan Dunklau a écrit : > Le mercredi 6 juillet 2022, 16:41:29 CEST Tom Lane a écrit : > > 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. > > For gist and sp-gist, a descent cost is taken into account, by estimating the > tree height so that particular effect is mitigated. Whether the cpu cost > estimation is sensible regarding to btree is another topic, but at least the > index cost doesn't vanish when inside a loop. > > Hash, brin and bloom are quite different, so maybe another examination would be > required but probably outside the scope of this bug report. Here is a patch tentatively addressing the problem. I'm not sure what I'm doing with the number of searched entries is right though. -- Ronan Dunklau
Commits
-
Improve GIN cost estimation
- cd9479af2af2 16.0 landed