From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
Cc: | Ahmed Ibrahim <ahmed(dot)ibr(dot)hashim(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Issue in _bt_getrootheight |
Date: | 2023-07-21 17:41:56 |
Message-ID: | 971650.1689961316@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gurjeet Singh <gurjeet(at)singh(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-07-21 18:30:22 | Re: MERGE ... RETURNING |
Previous Message | Tristan Partin | 2023-07-21 17:22:06 | Re: Use COPY for populating all pgbench tables |