Re: Issue in _bt_getrootheight

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

In response to

Responses

Browse pgsql-hackers by date

  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