Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o97D4-0006nq-Tn for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Jul 2022 15:45:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o97D3-0003Vp-Q9 for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Jul 2022 15:45:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o97D3-0003VO-GI for pgsql-bugs@lists.postgresql.org; Wed, 06 Jul 2022 15:45:01 +0000 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o97D1-0008TV-2b for pgsql-bugs@lists.postgresql.org; Wed, 06 Jul 2022 15:45:01 +0000 Received: by mail-wr1-x432.google.com with SMTP id q9so22639250wrd.8 for ; Wed, 06 Jul 2022 08:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=from:to:cc:subject:date:message-id:organization:in-reply-to :references:mime-version:content-transfer-encoding; bh=pVznAMPrXnSAVUIwGl5ykwzSW2sUFnDJggRE/prys9Y=; b=dp3w92aOZJiDCI32gvekiuUsbdYFirN4Bg06U+ZmcxkCMHe8koFifrB7qF+6frfC3I QM0dok+KqIPHkaT7D7OsX9WMycWV6LFNt4GHR+UTcCWKzyNEOq0txivIkwg6Syp1CTuC o7pvpLeIH2mkTgj8E079UuAjKvRbOCqtVbiOE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :in-reply-to:references:mime-version:content-transfer-encoding; bh=pVznAMPrXnSAVUIwGl5ykwzSW2sUFnDJggRE/prys9Y=; b=C9yiTz1SP0ZONQFv/jEiWuIqE7uT0aC8GyiMuN4dzkkygG5ios7MZ7WPgZfjf/9SGr VigP4dZKFFtAkgykDq+1Or8ZhXnLXiWKpJllK9MmdhjMlPekR4lV+AKxLSWnNRZpu01l YaZmW9QhAEZrmrUmi+zJmBVERQ9wJpTbRzv69Y2r2MlzVPB+t52hHj2mFs2ZSthyYATj 8tIdQakeQqZcFMJHGOLC5QDNKsCuJFV5jvD5ib0uNKWOfQLzDf7oE4hzpazw91emTtWD YGKRb5dLUZYTnX/oOrtr1NlcJKOwVZIHzy1cr5WzDVFEiajM/NtCYRDtvPUNGwpPtz9j okug== X-Gm-Message-State: AJIora8dhqJjeDFdzkVTFn5E6hh8v7tLoJWizYQXgiuc3QH5KKsfFND6 U5VX+0UrTR3nH9C0MAYEUqjI7Q== X-Google-Smtp-Source: AGRyM1uanMbt3bL5lVIn5xI1NJlOyyK6CS56QagrsM4ryRLRxGg3Tin7M27TOi7V+nkM2SULKz3n5Q== X-Received: by 2002:adf:eccb:0:b0:21d:7b41:22c7 with SMTP id s11-20020adfeccb000000b0021d7b4122c7mr4495715wro.543.1657122297789; Wed, 06 Jul 2022 08:44:57 -0700 (PDT) Received: from aivenronan.localnet ([45.13.105.93]) by smtp.gmail.com with ESMTPSA id o11-20020a05600c4fcb00b003942a244f40sm23727321wmq.25.2022.07.06.08.44.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jul 2022 08:44:56 -0700 (PDT) From: Ronan Dunklau To: Tom Lane , pgsql-bugs@lists.postgresql.org Cc: Hung Nguyen , pgsql-bugs@lists.postgresql.org, "rjuju123@gmail.com" , Ronan Dunklau Subject: Re: index cost estimation Date: Wed, 06 Jul 2022 17:42:28 +0200 Message-ID: <3439542.iIbC2pHGDl@aivenronan> Organization: aiven In-Reply-To: <2187702.iZASKD2KPV@aivenronan> References: <2194637.1657118489@sss.pgh.pa.us> <2187702.iZASKD2KPV@aivenronan> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart8958947.CDJkKcVGEf" Content-Transfer-Encoding: 7Bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --nextPart8958947.CDJkKcVGEf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Le mercredi 6 juillet 2022, 16:52:09 CEST Ronan Dunklau a =E9crit : > 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. >=20 > For gist and sp-gist, a descent cost is taken into account, by estimating= =20 the > tree height so that particular effect is mitigated. Whether the cpu cost > estimation is sensible regarding to btree is another topic, but at least = the > index cost doesn't vanish when inside a loop. >=20 > Hash, brin and bloom are quite different, so maybe another examination wo= uld=20 be > required but probably outside the scope of this bug report. Here is a patch tentatively addressing the problem. I'm not sure what I'm=20 doing with the number of searched entries is right though. =2D-=20 Ronan Dunklau --nextPart8958947.CDJkKcVGEf Content-Disposition: attachment; filename="v1-0001-Fix-gin-costing.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="v1-0001-Fix-gin-costing.patch"