Re: Issue in _bt_getrootheight
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Gurjeet Singh <gurjeet@singh.im>
Cc: Ahmed Ibrahim <ahmed.ibr.hashim@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2023-07-21T17:41:56Z
Lists: pgsql-hackers
Gurjeet Singh <gurjeet@singh.im> writes:
> Please see attached the patch that does this. Let me know if this patch helps.
I don't like this patch one bit, because it adds a lot of overhead
(i.e., an extra index_open/close cycle for every btree index in every
query) to support a tiny minority use-case. How come we don't
already know whether the index is hypothetical at the point where
_bt_getrootheight is called now?
Actually, looking at the existing comment at the call site:
/*
* Allow a plugin to editorialize on the info we obtained from the
* catalogs. Actions might include altering the assumed relation size,
* removing an index, or adding a hypothetical index to the indexlist.
*/
if (get_relation_info_hook)
(*get_relation_info_hook) (root, relationObjectId, inhparent, rel);
reminds me that the design intention was that hypothetical indexes
would get added to the list by get_relation_info_hook itself.
If that's not how the index adviser is operating, maybe we need
to have a discussion about that.
regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Redesign the planner's handling of index-descent cost estimation.
- 31f38f28b00c 9.3.0 cited