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 1p138P-0003HU-My for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Dec 2022 10:19:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p138O-0002Tu-D8 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Dec 2022 10:19:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p138N-0002RI-Pf for pgsql-hackers@lists.postgresql.org; Fri, 02 Dec 2022 10:19:07 +0000 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p138K-00066A-Tp for pgsql-hackers@lists.postgresql.org; Fri, 02 Dec 2022 10:19:06 +0000 Received: by mail-wm1-x335.google.com with SMTP id m19so3193993wms.5 for ; Fri, 02 Dec 2022 02:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pWbprIwwb9cUvBzdNPw6W8hoOZN9yaEhphYSUIuAsdw=; b=myjy11TRVV52XFaaS141S3/3bFMLrCosS+z9Mi+Cur/K8ZVkr1TEsspVF6D8ttwZ/z u/KMFnHfdzO5mVYfHkLAS+nFFOEoCFJdrqvhDjAdlMca2Ido0AUnF06VCQa/MZRCsfFt VHnIyGEZcP13eze9wnMbzIEI9y5dXvj/K0IUk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pWbprIwwb9cUvBzdNPw6W8hoOZN9yaEhphYSUIuAsdw=; b=GMtJ2eddBCCb4y70Zl2gyc1uH/I4wbcYIVZfCse18bqpvGmXs+fOu7R3K8BUcRm3GU ZAgj+kCdSCOYXEXZKf4TeSmjONb+6Fcurof3Y8BYnr3BJGdchNaJfLIoDLpLzgaIE10O viKRYBi3uAySJ61JlnoO/GwdvVhBeKB+XhDonklB0uDRItAETS1u1dQqCg+jx6sDDtKk XjBwUursFgzf8EnY7E0EYTtSqb5uStZXDzg0qDQU+DLJZ9rXyjxO0XA/izipvNBpCvQ1 tbF6DITZs0DnzlSRKTcqMoOq93oxkB+ecSKSpPEnaxQlPZO4jkDTSFc9dt+q7aZEp6cX Rgxw== X-Gm-Message-State: ANoB5pnahTIUtcturModhxJSv0JTCggZ0MEAtM4vPx5Vtkax1zAsuPhj /vVtV0uC43TGbws01GI0QQ29hQ== X-Google-Smtp-Source: AA0mqf4lnm90HjbRZhZKMrhGaJu1fByd6u6cvs5Csu9MJFeAZ5uaCzqDUdi1mhTgpRVOxwGv41b6Mg== X-Received: by 2002:a05:600c:3c82:b0:3d0:59cd:5a65 with SMTP id bg2-20020a05600c3c8200b003d059cd5a65mr17460681wmb.69.1669976342703; Fri, 02 Dec 2022 02:19:02 -0800 (PST) Received: from aivenlaptop.localnet ([45.13.105.93]) by smtp.gmail.com with ESMTPSA id g6-20020a05600c4ec600b003b49bd61b19sm13736200wmq.15.2022.12.02.02.19.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 02:19:01 -0800 (PST) From: Ronan Dunklau To: Alexander Korotkov , Tom Lane Cc: Michael Paquier , pgsql-hackers@lists.postgresql.org Subject: Re: Fix gin index cost estimation Date: Fri, 02 Dec 2022 11:19:11 +0100 Message-ID: <13151261.uLZWGnKmhe@aivenlaptop> In-Reply-To: <4011931.1666707537@sss.pgh.pa.us> References: <3188617.44csPzL39Z@aivenronan> <4011931.1666707537@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2856501.e9J7NaK4W3" 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. --nextPart2856501.e9J7NaK4W3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Le mardi 25 octobre 2022, 16:18:57 CET Tom Lane a =E9crit : > Alexander Korotkov writes: > > I think Tom's point was that it's wrong to add a separate entry-tree CPU > > cost estimation to another estimation, which tries (very inadequately) = to > > estimate the whole scan cost. Instead, I propose writing better > > estimations > > for both entry-tree CPU cost and data-trees CPU cost and replacing > > existing > > CPU estimation altogether. >=20 > Great idea, if someone is willing to do it ... >=20 > regards, tom lane Hello, Sorry for the delay, but here is an updated patch which changes the costing= in=20 the following way: =2D add a descent cost similar to the btree one is charged for the initial= =20 entry-tree =2D additionally, a charge is applied per page in both the entry tree and=20 posting trees / lists =2D instead of charging the quals to each tuple, charge them per entry only= =2E We=20 still charge cpu_index_tuple_cost per tuple though. With those changes, no need to tweak the magic number formula estimating th= e=20 number of pages. Maybe we can come up with something better for estimating= =20 those later on ? Best regards, =2D- Ronan Dunklau --nextPart2856501.e9J7NaK4W3 Content-Disposition: attachment; filename="v3-0001-Fix-gin-costing.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="v3-0001-Fix-gin-costing.patch"