From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
cc: Hung Nguyen <hungnq1989@gmail.com>, pgsql-bugs@lists.postgresql.org,
        "rjuju123@gmail.com" <rjuju123@gmail.com>
Subject: Re: index cost estimation
In-reply-to: <2834175.e9J7NaK4W3@aivenronan>
References: 
 <CABs3KGQnOkyQ42-zKQqiE7M0Ks9oWDSee=+Jx3-TGq=68xqWYw@mail.gmail.com>
 <263303.1656769531@sss.pgh.pa.us> <2834175.e9J7NaK4W3@aivenronan>
Comments: In-reply-to Ronan Dunklau <ronan.dunklau@aiven.io>
	message dated "Wed, 06 Jul 2022 10:53:52 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2194636.1657118489.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 06 Jul 2022 10:41:29 -0400
Message-ID: <2194637.1657118489@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2194637.1657118489%40sss.pgh.pa.us>
Precedence: bulk

Ronan Dunklau <ronan.dunklau@aiven.io> writes:
> Looking into it, it looks like we are not charging a cpu "descent" cost =
for =

> the entry tree of the gin index, which we do for the btree index. In gen=
eral, =

> it does not pose a problem since IO costs are far greater than cpu costs=
. But =

> when the index scan is inside a nestloop, we account for cache effect an=
d =

> amortize the cost of IO over the number of outer scans, which reduces it=
s =

> relative importance significantly. In that case, the index scan on the g=
in =

> index appears much cheaper, as the constant cpu cost is not taken into =

> account. =


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.

			regards, tom lane