From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: Hung Nguyen <hungnq1989@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, "rjuju123@gmail.com" <rjuju123@gmail.com>
Subject: Re: index cost estimation
Date: Wed, 06 Jul 2022 10:41:29 -0400
Message-ID: <2194637.1657118489@sss.pgh.pa.us> (raw)
In-Reply-To: <2834175.e9J7NaK4W3@aivenronan>
References: <CABs3KGQnOkyQ42-zKQqiE7M0Ks9oWDSee=+Jx3-TGq=68xqWYw@mail.gmail.com>
<263303.1656769531@sss.pgh.pa.us>
<2834175.e9J7NaK4W3@aivenronan>
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 general,
> 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 and
> amortize the cost of IO over the number of outer scans, which reduces its
> relative importance significantly. In that case, the index scan on the gin
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, ronan.dunklau@aiven.io, hungnq1989@gmail.com, rjuju123@gmail.com
Subject: Re: index cost estimation
In-Reply-To: <2194637.1657118489@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox