MIME-Version: 1.0
References: <3188617.44csPzL39Z@aivenronan> <4768224.31r3eYUQgx@aivenronan>
 <Y0ZOqzshes0++b1x@paquier.xyz> <12071145.O9o76ZdvQC@aivenronan>
In-Reply-To: <12071145.O9o76ZdvQC@aivenronan>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Tue, 25 Oct 2022 17:08:58 +0300
Message-ID: 
 <CAPpHfdt45WZPcS-R1BYLgixv+vW_+dTom6GHa-XZPu4mtfXTRg@mail.gmail.com>
Subject: Re: Fix gin index cost estimation
To: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000a91aa605ebdc7342"
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdt45WZPcS-R1BYLgixv%2BvW_%2BdTom6GHa-XZPu4mtfXTRg%40mail.gmail.com>
Precedence: bulk

--000000000000a91aa605ebdc7342
Content-Type: text/plain; charset="UTF-8"

Hi, Ronan!

On Wed, Oct 12, 2022 at 10:15 AM Ronan Dunklau <ronan.dunklau@aiven.io>
wrote:
> > > You're right, I was too eager to try to raise the CPU cost
proportionnally
> to
> > > the number of array scans (scalararrayop). I'd really like to
understand
> where
> > > this equation comes from though...
> >
> > So, what's the latest update here?
>
> Thanks Michael for reviving this thread.
>
> Before proceeding any further with this, I'd like to understand where we
> stand. Tom argued my way of charging cost per entry pages visited boils
down
> to charging per tuple, which I expressed disagreement with.
>
> If we can come to a consensus whether that's a bogus way of thinking
about it
> I'll proceed with what we agree on.

I briefly read the thread. I think this line is copy-paste from other index
access methods and trying to estimate the whole index scan CPU cost by
bypassing all the details.

*indexTotalCost += (numTuples * *indexSelectivity) * (cpu_index_tuple_cost
+ qual_op_cost);

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.

------
Regards,
Alexander Korotkov

--000000000000a91aa605ebdc7342
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi, Ronan!<br><br>On Wed, Oct 12, 2022 at 10:15 AM Ronan D=
unklau &lt;<a href=3D"mailto:ronan.dunklau@aiven.io">ronan.dunklau@aiven.io=
</a>&gt; wrote:<br>&gt; &gt; &gt; You&#39;re right, I was too eager to try =
to raise the CPU cost proportionnally<br>&gt; to<br>&gt; &gt; &gt; the numb=
er of array scans (scalararrayop). I&#39;d really like to understand<br>&gt=
; where<br>&gt; &gt; &gt; this equation comes from though...<br>&gt; &gt;<b=
r>&gt; &gt; So, what&#39;s the latest update here?<br>&gt;<br>&gt; Thanks M=
ichael for reviving this thread.<br>&gt;<br>&gt; Before proceeding any furt=
her with this, I&#39;d like to understand where we<br>&gt; stand. Tom argue=
d my way of charging cost per entry pages visited boils down<br>&gt; to cha=
rging per tuple, which I expressed disagreement with.<br>&gt;<br>&gt; If we=
 can come to a consensus whether that&#39;s a bogus way of thinking about i=
t<br>&gt; I&#39;ll proceed with what we agree on.<br><br>I briefly read the=
 thread. I think this line is copy-paste from other index access methods an=
d trying to estimate the whole index scan CPU cost by bypassing all the det=
ails.<br><br><font face=3D"monospace">*indexTotalCost +=3D (numTuples * *in=
dexSelectivity) * (cpu_index_tuple_cost + qual_op_cost);<br></font><br>I th=
ink Tom&#39;s point was that it&#39;s wrong to add a separate entry-tree CP=
U cost estimation to another estimation, which tries (very inadequately) to=
 estimate the whole scan cost. Instead, I propose writing better estimation=
s for both entry-tree CPU cost and data-trees CPU cost and replacing existi=
ng CPU estimation altogether.<div><br>------<br>Regards,<br>Alexander Korot=
kov</div></div>

--000000000000a91aa605ebdc7342--