MIME-Version: 1.0
References: <CAMbWs48jzLrPt1J_00ZcPZXWUQKawQOFE8ROc-ADiYqsqrpBNw@mail.gmail.com>
 <87il22cj51.fsf@163.com> <CAMbWs49=eAd2W9jCtGhaZPPp+SOC_2rg16RTG74xAht=hkr5JQ@mail.gmail.com>
 <CAMbWs49Nc4M3H+eCf1+8w8piDyEECjRb-gK_JMF4VvcyWwGEVQ@mail.gmail.com>
 <CAMbWs49E_dR0nobsExsyetpnBpHObLTsQLsEbWKQLkh0omPxNg@mail.gmail.com>
 <CAMbWs49B_qUiHvu2EqLHZRpLr3p_+QPBs50n2=L5ibYzniwTzA@mail.gmail.com>
 <CAMbWs48KCQtDymnYi4M=Vz+WMzo3fkBxffJsyk6VX6hOXXv+VA@mail.gmail.com>
 <CAMbWs49sv_MuOYqqrtmBN_oYf8VSQ2BXDwXaTpJTn_YfwyYdWQ@mail.gmail.com>
 <CAMbWs49U8Sddx_fGszPdvA3jp_nheynxaqm5Y4NqMV21VBYAuQ@mail.gmail.com>
 <CAMbWs4-LwyOg9ga+NVF7yQbMi0ZsZdN1G_sO2v=YJHV18=19+A@mail.gmail.com>
 <CALA8mJquG_zCJXfVwash5LKqHGtZXQmq7RfTSaRDUzGYeW=7Rw@mail.gmail.com>
 <CAMbWs4_EjgcBib5+y1LYcGB3EK3Y6R+OOxGKfJo42fDovadk1g@mail.gmail.com>
 <CALA8mJqe0anNM8_V6cOeOQnCHUTQggn7iOQNyQr1VaN_xMjz+w@mail.gmail.com>
 <CAMbWs48eE-s-jCicC8pSVfXk8Ws-ZvUKnsw8qH-DkVBdYv0eJQ@mail.gmail.com> <CAMbWs483a7-8M0pDttG44r-+8Gevn9VG0xNceE3WpkEQxJXPZw@mail.gmail.com>
In-Reply-To: <CAMbWs483a7-8M0pDttG44r-+8Gevn9VG0xNceE3WpkEQxJXPZw@mail.gmail.com>
From: Tender Wang <tndrwang@gmail.com>
Date: Wed, 28 Aug 2024 11:57:12 +0800
Message-ID: <CAHewXNmYM6DvR_kaxDL0w0fz9BwKbac+TSU3QS10aA3cXHyMmA@mail.gmail.com>
Subject: Re: Eager aggregation, take 3
To: Richard Guo <guofenglinux@gmail.com>
Cc: Paul George <p.a.george19@gmail.com>, Andy Fan <zhihuifan1213@163.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>, pgsql-hackers@lists.postgresql.org, 
	Robert Haas <robertmhaas@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000c83150620b65b31"
Archived-At: <https://www.postgresql.org/message-id/CAHewXNmYM6DvR_kaxDL0w0fz9BwKbac%2BTSU3QS10aA3cXHyMmA%40mail.gmail.com>
Precedence: bulk

--0000000000000c83150620b65b31
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Richard Guo <guofenglinux@gmail.com> =E4=BA=8E2024=E5=B9=B48=E6=9C=8821=E6=
=97=A5=E5=91=A8=E4=B8=89 15:11=E5=86=99=E9=81=93=EF=BC=9A

> On Fri, Aug 16, 2024 at 4:14=E2=80=AFPM Richard Guo <guofenglinux@gmail.c=
om>
> wrote:
> > I had a self-review of this patchset and made some refactoring,
> > especially to the function that creates the RelAggInfo structure for a
> > given relation.  While there were no major changes, the code should
> > now be simpler.
>
> I found a bug in v10 patchset: when we generate the GROUP BY clauses
> for the partial aggregation that is pushed down to a non-aggregated
> relation, we may produce a clause with a tleSortGroupRef that
> duplicates one already present in the query's groupClause, which would
> cause problems.
>
> Attached is the updated version of the patchset that fixes this bug
> and includes further code refactoring.
>

Rectenly, I do some benchmark tests, mainly on tpch and tpcds.
tpch tests have no plan diff, so I do not continue to test on tpch.
tpcds(10GB) tests have 22 plan diff as below:
4.sql, 5.sql, 8.sql,11.sql,19.sql,23.sql,31.sql,
33.sql,39.sql,45.sql,46.sql,47.sql,53.sql,
56.sql,57.sql,60.sql,63.sql,68.sql,74.sql,77.sql,80.sql,89.sql

I haven't look all of them. I just pick few simple plan test(e.g. 19.sql,
45.sql).
For example, 19.sql, eager agg pushdown doesn't get large gain, but a littl=
e
performance regress.

I will continue to do benchmark on this feature.

[1] https://github.com/tenderwg/eager_agg

--=20
Tender Wang

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Richard Guo &lt;<a href=3D"mailto:guo=
fenglinux@gmail.com">guofenglinux@gmail.com</a>&gt; =E4=BA=8E2024=E5=B9=B48=
=E6=9C=8821=E6=97=A5=E5=91=A8=E4=B8=89 15:11=E5=86=99=E9=81=93=EF=BC=9A<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Aug 16, 202=
4 at 4:14=E2=80=AFPM Richard Guo &lt;<a href=3D"mailto:guofenglinux@gmail.c=
om" target=3D"_blank">guofenglinux@gmail.com</a>&gt; wrote:<br>
&gt; I had a self-review of this patchset and made some refactoring,<br>
&gt; especially to the function that creates the RelAggInfo structure for a=
<br>
&gt; given relation.=C2=A0 While there were no major changes, the code shou=
ld<br>
&gt; now be simpler.<br>
<br>
I found a bug in v10 patchset: when we generate the GROUP BY clauses<br>
for the partial aggregation that is pushed down to a non-aggregated<br>
relation, we may produce a clause with a tleSortGroupRef that<br>
duplicates one already present in the query&#39;s groupClause, which would<=
br>
cause problems.<br>
<br>
Attached is the updated version of the patchset that fixes this bug<br>
and includes further code refactoring.<br></blockquote><div><br></div><div>=
Rectenly, I do some benchmark tests, mainly on tpch and tpcds.</div><div>tp=
ch tests have no plan diff, so I do not continue to test on tpch.</div><div=
>tpcds(10GB) tests have 22 plan diff as below:</div><div>4.sql, 5.sql, 8.sq=
l,11.sql,19.sql,23.sql,31.sql, 33.sql,39.sql,45.sql,46.sql,47.sql,53.sql,</=
div><div>56.sql,57.sql,60.sql,63.sql,68.sql,74.sql,77.sql,80.sql,89.sql</di=
v><div><br></div><div>I haven&#39;t look all of them. I just pick few simpl=
e plan test(e.g. 19.sql, 45.sql).</div><div>For example, 19.sql, eager agg =
pushdown doesn&#39;t get large gain, but a little</div><div>performance reg=
ress.</div><div><br></div><div>I will continue to do benchmark on this feat=
ure.</div><div><br></div><div>[1]=C2=A0<a href=3D"https://github.com/tender=
wg/eager_agg">https://github.com/tenderwg/eager_agg</a></div></div><div><br=
></div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr=
" class=3D"gmail_signature"><div dir=3D"ltr"><div>Tender Wang</div></div></=
div></div>

--0000000000000c83150620b65b31--