From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hung Nguyen <hungnq1989@gmail.com>, pgsql-bugs@lists.postgresql.org,
 "rjuju123@gmail.com" <rjuju123@gmail.com>
Subject: Re: index cost estimation
Date: Wed, 06 Jul 2022 16:52:09 +0200
Message-ID: <2187702.iZASKD2KPV@aivenronan>
Organization: aiven
In-Reply-To: <2194637.1657118489@sss.pgh.pa.us>
References: 
 <CABs3KGQnOkyQ42-zKQqiE7M0Ks9oWDSee=+Jx3-TGq=68xqWYw@mail.gmail.com>
 <2834175.e9J7NaK4W3@aivenronan> <2194637.1657118489@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: 
 <https://www.postgresql.org/message-id/2187702.iZASKD2KPV%40aivenronan>
Precedence: bulk

Le mercredi 6 juillet 2022, 16:41:29 CEST Tom Lane a =E9crit :
> 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.

=46or gist and sp-gist, a descent cost is taken into account, by estimating=
 the=20
tree height so that particular effect is mitigated. Whether the cpu cost=20
estimation is sensible regarding to btree is another topic, but at least th=
e=20
index cost doesn't vanish when inside a loop.

Hash, brin and bloom are quite different, so maybe another examination woul=
d be=20
required but probably outside the scope of this bug report.=20


=2D-=20
Ronan Dunklau