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>
 <CAHewXNmNN6nu_ZTqESEXjyaXAU2w7DV22P8Vhijg9AJNv0uGLA@mail.gmail.com>
 <CAMbWs49r+6WBszieGpEGnhacD+yo_rU85m7NZ=TFu3oiNHmvmw@mail.gmail.com> <CA+TgmoaUn4w+1y2Z-+paWW3oNSMhAFny-KxudCREb3MpGZyUbQ@mail.gmail.com>
In-Reply-To: <CA+TgmoaUn4w+1y2Z-+paWW3oNSMhAFny-KxudCREb3MpGZyUbQ@mail.gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
Date: Fri, 1 Nov 2024 10:50:24 +0900
Message-ID: <CAMbWs4_GQbo510O2cJLrVCZ+zZ2yt_Y24KV37AiMDVtJnzybMA@mail.gmail.com>
Subject: Re: Eager aggregation, take 3
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>, Paul George <p.a.george19@gmail.com>, 
	Andy Fan <zhihuifan1213@163.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAMbWs4_GQbo510O2cJLrVCZ%2BzZ2yt_Y24KV37AiMDVtJnzybMA%40mail.gmail.com>
Precedence: bulk

On Tue, Oct 29, 2024 at 9:59=E2=80=AFPM Robert Haas <robertmhaas@gmail.com>=
 wrote:
> On Wed, Sep 25, 2024 at 3:03=E2=80=AFAM Richard Guo <guofenglinux@gmail.c=
om> wrote:
> > On Wed, Sep 11, 2024 at 10:52=E2=80=AFAM Tender Wang <tndrwang@gmail.co=
m> wrote:
> > > 1. In make_one_rel(), we have the below codes:
> > > /*
> > > * Build grouped base relations for each base rel if possible.
> > > */
> > > setup_base_grouped_rels(root);
> > >
> > > As far as I know, each base rel only has one grouped base relation, i=
f possible.
> > > The comments may be changed to "Build a grouped base relation for eac=
h base rel if possible."
> >
> > Yeah, each base rel has only one grouped rel.  However, there is a
> > comment nearby stating 'consider_parallel flags for each base rel',
> > which confuses me about whether it should be singular or plural in
> > this context.  Perhaps someone more proficient in English could
> > clarify this.
>
> It's not confusing the way you have it, but I think an English teacher
> wouldn't like it, because part of the sentence is singular ("each base
> rel") and the other part is plural ("grouped base relations").
> Tender's proposed rewrite fixes that. Another way to fix it is to
> write "Build group relations for base rels where possible".

Thank you for the suggestion.  The new wording looks much better
grammatically.  It seems to me that we should address the nearby
comment too, which goes like "consider_parallel flags for each base
rel", as each rel has only one consider_parallel flag.

> > > 2.  According to the comments of generate_grouped_paths(), we may gen=
erate paths for a grouped
> > > relation on top of paths of join relation. So the =E2=80=9Drel_plain"=
 argument in generate_grouped_paths() may be
> > > confused. "plain" usually means "base rel" . How about Re-naming rel_=
plain to input_rel?
> >
> > I don't think 'plain relation' necessarily means 'base relation'.  In
> > this context I think it can mean 'non-grouped relation'.  But maybe
> > I'm wrong.
>
> We use the term "plain relation" in several different ways. In the
> header comments for addFkRecurseReferenced, it means a non-partitioned
> relation. In the struct comments for RangeTblEntry, it means any sort
> of named thing in pg_class that you can scan, so either a partitioned
> or unpartitioned table but not a join or a table function or
> something. AFAICT, the most common meaning of "plain relation" is a
> pg_class entry where relkind=3D=3DRELKIND_RELATION.

Agreed.

Thanks
Richard