MIME-Version: 1.0
References: 
 <CAMbWs48jzLrPt1J_00ZcPZXWUQKawQOFE8ROc-ADiYqsqrpBNw@mail.gmail.com>
In-Reply-To: 
 <CAMbWs48jzLrPt1J_00ZcPZXWUQKawQOFE8ROc-ADiYqsqrpBNw@mail.gmail.com>
From: Radim Marek <radim@boringsql.com>
Date: Fri, 29 May 2026 17:55:01 +0200
Message-ID: 
 <CAJgoLk+d_P5sKrx-SZt01Acm_j0QnWn6aKJzFJ=waRu_3C8AoQ@mail.gmail.com>
Subject: Re: Eager aggregation, take 3
To: Richard Guo <guofenglinux@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000bc2c190652f6de50"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJgoLk%2Bd_P5sKrx-SZt01Acm_j0QnWn6aKJzFJ%3DwaRu_3C8AoQ%40mail.gmail.com>
Precedence: bulk

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

Hey Richard,

I might be out of my depth here - but while testing RegreSQL as
correctness/performance harness on PostgreSQL it picked up a problem with
the wrong-results case during eager aggregation.

It reproduces on current HEAD
(commit 2670cc298f42cd7b1c426bf7ccfb0652d8e0b347 now)
with enable_eager_aggregate enabled.

My testing environment
  - Linux aarch64, gcc 12 (Debian)
  - macOS arm64, Apple clang 21
    (PostgreSQL 19devel on aarch64-apple-darwin25.5.0)

== How to reproduce

  CREATE TEMP TABLE c(id int, country text);
  CREATE TEMP TABLE o(customer_id int);
  INSERT INTO c VALUES (1,'US'),(2,'US'),(3,'DE'),(4,'DE'),(5,'DE');
  INSERT INTO o VALUES (1),(3);   -- only customers 1 and 3 have a row in o

  SELECT c.country, count(*) AS n
  FROM c
  WHERE NOT EXISTS (SELECT 1 FROM o WHERE o.customer_id = c.id)
  GROUP BY c.country
  ORDER BY c.country;

Expected results (everywhere except master)

 country | n
---------+---
 DE      | 2
 US      | 1
(2 rows)

The actual result with enable_eager_aggregate = on (default)

 country | n
---------+---
 DE      | 0
 US      | 0
(2 rows)

With SET enable_eager_aggregate = off, the result is correct (DE=2, US=1),
as it is on PG18.

Query Plan

                                                            QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=108.19..108.69 rows=200 width=40) (actual time=0.195..0.197
rows=2.00 loops=1)
   Sort Key: c.country
   Sort Method: quicksort  Memory: 25kB
   Buffers: local hit=2
   ->  Finalize HashAggregate  (cost=98.55..100.55 rows=200 width=40)
(actual time=0.183..0.186 rows=2.00 loops=1)
         Group Key: c.country
         Batches: 1  Memory Usage: 32kB
         Buffers: local hit=2
         ->  Hash Anti Join  (cost=52.75..95.37 rows=635 width=40) (actual
time=0.177..0.179 rows=3.00 loops=1)
               Hash Cond: (c.id = o.customer_id)
               Buffers: local hit=2
               ->  Seq Scan on c  (cost=0.00..22.70 rows=1270 width=36)
(actual time=0.024..0.025 rows=5.00 loops=1)
                     Buffers: local hit=1
               ->  Hash  (cost=50.25..50.25 rows=200 width=12) (actual
time=0.145..0.146 rows=2.00 loops=1)
                     Buckets: 1024  Batches: 1  Memory Usage: 9kB
                     Buffers: local hit=1
                     ->  Partial HashAggregate  (cost=48.25..50.25 rows=200
width=12) (actual time=0.122..0.123 rows=2.00 loops=1)
                           Group Key: o.customer_id
                           Batches: 1  Memory Usage: 32kB
                           Buffers: local hit=1
                           ->  Seq Scan on o  (cost=0.00..35.50 rows=2550
width=4) (actual time=0.002..0.003 rows=2.00 loops=1)
                                 Buffers: local hit=1
 Planning Time: 0.294 ms
 Execution Time: 0.255 ms
(24 rows)

If this is already known or in progress, apologies for the noise.

---

Radim

On Fri, 29 May 2026 at 17:25, Richard Guo <guofenglinux@gmail.com> wrote:

> Hi All,
>
> Eager aggregation is a query optimization technique that partially
> pushes a group-by past a join, and finalizes it once all the relations
> are joined.  Eager aggregation reduces the number of input rows to the
> join and thus may result in a better overall plan.  This technique is
> thoroughly described in the 'Eager Aggregation and Lazy Aggregation'
> paper [1].
>
> Back in 2017, a patch set has been proposed by Antonin Houska to
> implement eager aggregation in thread [2].  However, it was at last
> withdrawn after entering the pattern of "please rebase thx" followed by
> rebasing and getting no feedback until "please rebase again thx".  A
> second attempt in 2022 unfortunately fell into the same pattern about
> one year ago and was eventually closed again [3].
>
> That patch set has included most of the necessary concepts to implement
> eager aggregation.  However, as far as I can see, it has several weak
> points that we need to address.  It introduces invasive changes to some
> core planner functions, such as make_join_rel().  And with such changes
> join_is_legal() would be performed three times for the same proposed
> join, which is not great.  Another weak point is that the complexity of
> join searching dramatically increases with the growing number of
> relations to be joined.  This occurs because when we generate partially
> aggregated paths, each path of the input relation is considered as an
> input path for the grouped paths.  As a result, the number of grouped
> paths we generate increases exponentially, leading to a significant
> explosion in computational complexity.  Other weak points include the
> lack of support for outer joins and partitionwise joins.  And during my
> review of the code, I came across several bugs (planning error or crash)
> that need to be addressed.
>
> I'd like to give it another take to implement eager aggregation, while
> borrowing lots of concepts and many chunks of codes from the previous
> patch set.  Please see attached.  I have chosen to use the term 'Eager
> Aggregation' from the paper [1] instead of 'Aggregation push-down', to
> differentiate the aggregation push-down technique in FDW.
>
> The patch has been split into small pieces to make the review easier.
>
> 0001 introduces the RelInfoList structure, which encapsulates both a
> list and a hash table, so that we can leverage the hash table for faster
> lookups not only for join relations but also for upper relations.  With
> eager aggregation, it is possible that we generate so many upper rels of
> type UPPERREL_PARTIAL_GROUP_AGG that a hash table can help a lot with
> lookups.
>
> 0002 introduces the RelAggInfo structure to store information needed to
> create grouped paths for base and join rels.  It also revises the
> RelInfoList related structures and functions so that they can be used
> with RelAggInfos.
>
> 0003 checks if eager aggregation is applicable, and if so, collects
> suitable aggregate expressions and grouping expressions in the query,
> and records them in root->agg_clause_list and root->group_expr_list
> respectively.
>
> 0004 implements the functions that check if eager aggregation is
> applicable for a given relation, and if so, create RelAggInfo structure
> for the relation, using the infos about aggregate expressions and
> grouping expressions we collected earlier.  In this patch, when we check
> if a target expression can act as grouping expression, we need to check
> if this expression can be known equal to other expressions due to ECs
> that can act as grouping expressions.  This patch leverages function
> exprs_known_equal() to achieve that, after enhancing this function to
> consider opfamily if provided.
>
> 0005 implements the functions that generate paths for grouped relations
> by adding sorted and hashed partial aggregation paths on top of paths of
> the plain base or join relations.  For sorted partial aggregation paths,
> we only consider any suitably-sorted input paths as well as sorting the
> cheapest-total path.  For hashed partial aggregation paths, we only
> consider the cheapest-total path as input.  By not considering other
> paths we can reduce the number of grouping paths as much as possible
> while still achieving reasonable results.
>
> 0006 builds grouped relations for each base relation if possible, and
> generates aggregation paths for the grouped base relations.
>
> 0007 builds grouped relations for each just-processed join relation if
> possible, and generates aggregation paths for the grouped join
> relations.  The changes made to make_join_rel() are relatively minor,
> with the addition of a new function make_grouped_join_rel(), which finds
> or creates a grouped relation for the just-processed joinrel, and
> generates grouped paths by joining a grouped input relation with a
> non-grouped input relation.
>
> The other way to generate grouped paths is by adding sorted and hashed
> partial aggregation paths on top of paths of the joinrel.  This occurs
> in standard_join_search(), after we've run set_cheapest() for the
> joinrel.  The reason for performing this step after set_cheapest() is
> that we need to know the joinrel's cheapest paths (see 0005).
>
> This patch also makes the grouped relation for the topmost join rel act
> as the upper rel representing the result of partial aggregation, so that
> we can add the final aggregation on top of that.  Additionally, this
> patch extends the functionality of eager aggregation to work with
> partitionwise join and geqo.
>
> This patch also makes eager aggregation work with outer joins.  With
> outer join, the aggregate cannot be pushed down if any column referenced
> by grouping expressions or aggregate functions is nullable by an outer
> join above the relation to which we want to apply the partiall
> aggregation.  Thanks to Tom's outer-join-aware-Var infrastructure, we
> can easily identify such situations and subsequently refrain from
> pushing down the aggregates.
>
> Starting from this patch, you should be able to see plans with eager
> aggregation.
>
> 0008 adds test cases for eager aggregation.
>
> 0009 adds a section in README that describes this feature (copied from
> previous patch set, with minor tweaks).
>
> Thoughts and comments are welcome.
>
> [1] https://www.vldb.org/conf/1995/P345.PDF
> [2] https://www.postgresql.org/message-id/flat/9666.1491295317%40localhost
> [3]
> https://www.postgresql.org/message-id/flat/OS3PR01MB66609589B896FBDE190209F495EE9%40OS3PR01MB6660.jpnprd01.prod.outlook.com
>
> Thanks
> Richard
>

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

<div dir=3D"ltr"><div>Hey Richard,</div><div><br></div><div>I might be out =
of my depth here - but while testing RegreSQL as correctness/performance ha=
rness on PostgreSQL it picked up a problem with the=C2=A0wrong-results case=
 during eager aggregation.</div><div><br></div><div>It reproduces on curren=
t HEAD (commit=C2=A02670cc298f42cd7b1c426bf7ccfb0652d8e0b347 now) with=C2=
=A0enable_eager_aggregate enabled.</div><div><br></div><div>My testing envi=
ronment</div><div>=C2=A0 - Linux aarch64, gcc 12 (Debian)<br>=C2=A0 - macOS=
 arm64, Apple clang 21<br>=C2=A0 =C2=A0 (PostgreSQL 19devel on aarch64-appl=
e-darwin25.5.0)</div><div><br></div><div>=3D=3D How to reproduce</div><div>=
<br></div><div>=C2=A0 CREATE TEMP TABLE c(id int, country text);<br>=C2=A0 =
CREATE TEMP TABLE o(customer_id int);<br>=C2=A0 INSERT INTO c VALUES (1,=
9;US&#39;),(2,&#39;US&#39;),(3,&#39;DE&#39;),(4,&#39;DE&#39;),(5,&#39;DE=
9;);<br>=C2=A0 INSERT INTO o VALUES (1),(3); =C2=A0 -- only customers 1 and=
 3 have a row in o<br><br>=C2=A0 SELECT c.country, count(*) AS n<br>=C2=A0 =
FROM c<br>=C2=A0 WHERE NOT EXISTS (SELECT 1 FROM o WHERE o.customer_id =3D =
<a href=3D"http://c.id">c.id</a>)<br>=C2=A0 GROUP BY c.country<br>=C2=A0 OR=
DER BY c.country;</div><div><br></div><div>Expected results (everywhere exc=
ept master)</div><div><br></div><div>=C2=A0country | n<br>---------+---<br>=
=C2=A0DE =C2=A0 =C2=A0 =C2=A0| 2<br>=C2=A0US =C2=A0 =C2=A0 =C2=A0| 1<br>(2 =
rows)</div><div><br></div><div>The actual result=C2=A0with enable_eager_agg=
regate =3D on (default)</div><div><br></div><div>=C2=A0country | n<br>-----=
----+---<br>=C2=A0DE =C2=A0 =C2=A0 =C2=A0| 0<br>=C2=A0US =C2=A0 =C2=A0 =C2=
=A0| 0<br>(2 rows)</div><div><br></div><div>With SET enable_eager_aggregate=
 =3D off, the result is correct (DE=3D2, US=3D1), as it is on PG18.</div><d=
iv><br></div><div>Query Plan<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 QUERY PLAN<br>------------------------------------=
---------------------------------------------------------------------------=
--------------------<br>=C2=A0Sort =C2=A0(cost=3D108.19..108.69 rows=3D200 =
width=3D40) (actual time=3D0.195..0.197 rows=3D2.00 loops=3D1)<br>=C2=A0 =
=C2=A0Sort Key: c.country<br>=C2=A0 =C2=A0Sort Method: quicksort =C2=A0Memo=
ry: 25kB<br>=C2=A0 =C2=A0Buffers: local hit=3D2<br>=C2=A0 =C2=A0-&gt; =C2=
=A0Finalize HashAggregate =C2=A0(cost=3D98.55..100.55 rows=3D200 width=3D40=
) (actual time=3D0.183..0.186 rows=3D2.00 loops=3D1)<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Group Key: c.country<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
Batches: 1 =C2=A0Memory Usage: 32kB<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bu=
ffers: local hit=3D2<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-&gt; =C2=A0Hash =
Anti Join =C2=A0(cost=3D52.75..95.37 rows=3D635 width=3D40) (actual time=3D=
0.177..0.179 rows=3D3.00 loops=3D1)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Hash Cond: (<a href=3D"http://c.id">c.id</a> =3D o.cust=
omer_id)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers:=
 local hit=3D2<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-&=
gt; =C2=A0Seq Scan on c =C2=A0(cost=3D0.00..22.70 rows=3D1270 width=3D36) (=
actual time=3D0.024..0.025 rows=3D5.00 loops=3D1)<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers: local hit=
=3D1<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-&gt; =C2=A0=
Hash =C2=A0(cost=3D50.25..50.25 rows=3D200 width=3D12) (actual time=3D0.145=
..0.146 rows=3D2.00 loops=3D1)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buckets: 1024 =C2=A0Batches: 1 =C2=A0Mem=
ory Usage: 9kB<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Buffers: local hit=3D1<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-&gt; =C2=A0Partial HashAgg=
regate =C2=A0(cost=3D48.25..50.25 rows=3D200 width=3D12) (actual time=3D0.1=
22..0.123 rows=3D2.00 loops=3D1)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group Key: o.cus=
tomer_id<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Batches: 1 =C2=A0Memory Usage: 32kB<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Buffers: local hit=3D1<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-&=
gt; =C2=A0Seq Scan on o =C2=A0(cost=3D0.00..35.50 rows=3D2550 width=3D4) (a=
ctual time=3D0.002..0.003 rows=3D2.00 loops=3D1)<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Buffers: local hit=3D1<br>=C2=A0Planning Time: 0.29=
4 ms<br>=C2=A0Execution Time: 0.255 ms<br>(24 rows)<br><br>If this is alrea=
dy known or in progress, apologies for the noise.</div><div><br></div><div>=
---</div><div><br></div><div>Radim</div></div><br><div class=3D"gmail_quote=
 gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 29 Ma=
y 2026 at 17:25, Richard Guo &lt;<a href=3D"mailto:guofenglinux@gmail.com">=
guofenglinux@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr">Hi All,<br><br>Eager aggregation is =
a query optimization technique that partially<br>pushes a group-by past a j=
oin, and finalizes it once all the relations<br>are joined.=C2=A0 Eager agg=
regation reduces the number of input rows to the<br>join and thus may resul=
t in a better overall plan.=C2=A0 This technique is<br>thoroughly described=
 in the &#39;Eager Aggregation and Lazy Aggregation&#39;<br>paper [1].<br><=
br>Back in 2017, a patch set has been proposed by Antonin Houska to<br>impl=
ement eager aggregation in thread [2].=C2=A0 However, it was at last<br>wit=
hdrawn after entering the pattern of &quot;please rebase thx&quot; followed=
 by<br>rebasing and getting no feedback until &quot;please rebase again thx=
&quot;. =C2=A0A<br>second attempt in 2022 unfortunately fell into the same =
pattern about<br>one year ago and was eventually closed again [3].<br><br>T=
hat patch set has included most of the necessary concepts to implement<br>e=
ager aggregation.=C2=A0 However, as far as I can see, it has several weak<b=
r>points that we need to address.=C2=A0 It introduces invasive changes to s=
ome<br>core planner functions, such as make_join_rel().=C2=A0 And with such=
 changes<br>join_is_legal() would be performed three times for the same pro=
posed<br>join, which is not great.=C2=A0 Another weak point is that the com=
plexity of<br>join searching dramatically increases with the growing number=
 of<br>relations to be joined.=C2=A0 This occurs because when we generate p=
artially<br>aggregated paths, each path of the input relation is considered=
 as an<br>input path for the grouped paths.=C2=A0 As a result, the number o=
f grouped<br>paths we generate increases exponentially, leading to a signif=
icant<br>explosion in computational complexity.=C2=A0 Other weak points inc=
lude the<br>lack of support for outer joins and partitionwise joins.=C2=A0 =
And during my<br>review of the code, I came across several bugs (planning e=
rror or crash)<br>that need to be addressed.<br><br>I&#39;d like to give it=
 another take to implement eager aggregation, while<br>borrowing lots of co=
ncepts and many chunks of codes from the previous<br>patch set.=C2=A0 Pleas=
e see attached.=C2=A0 I have chosen to use the term &#39;Eager<br>Aggregati=
on&#39; from the paper [1] instead of &#39;Aggregation push-down&#39;, to<b=
r>differentiate the aggregation push-down technique in FDW.<br><br>The patc=
h has been split into small pieces to make the review easier.<br><div><br><=
/div><div>0001 introduces the RelInfoList structure, which encapsulates bot=
h a<br>list and a hash table, so that we can leverage the hash table for fa=
ster<br>lookups not only for join relations but also for upper relations.=
=C2=A0 With<br>eager aggregation, it is possible that we generate so many u=
pper rels of<br>type UPPERREL_PARTIAL_GROUP_AGG that a hash table can help =
a lot with<br>lookups.<br><br>0002 introduces the RelAggInfo structure to s=
tore information needed to<br>create grouped paths for base and join rels.=
=C2=A0 It also revises the<br>RelInfoList related structures and functions =
so that they can be used<br>with RelAggInfos.<br><br>0003 checks if eager a=
ggregation is applicable, and if so, collects<br>suitable aggregate express=
ions and grouping expressions in the query,<br>and records them in root-&gt=
;agg_clause_list and root-&gt;group_expr_list<br>respectively.<br><br>0004 =
implements the functions that check if eager aggregation is<br>applicable f=
or a given relation, and if so, create RelAggInfo structure<br>for the rela=
tion, using the infos about aggregate expressions and<br>grouping expressio=
ns we collected earlier.=C2=A0 In this patch, when we check<br>if a target =
expression can act as grouping expression, we need to check<br>if this expr=
ession can be known equal to other expressions due to ECs<br>that can act a=
s grouping expressions.=C2=A0 This patch leverages function<br>exprs_known_=
equal() to achieve that, after enhancing this function to<br>consider opfam=
ily if provided.<br><br>0005 implements the functions that generate paths f=
or grouped relations<br>by adding sorted and hashed partial aggregation pat=
hs on top of paths of<br>the plain base or join relations.=C2=A0 For sorted=
 partial aggregation paths,<br>we only consider any suitably-sorted input p=
aths as well as sorting the<br>cheapest-total path.=C2=A0 For hashed partia=
l aggregation paths, we only<br>consider the cheapest-total path as input.=
=C2=A0 By not considering other<br>paths we can reduce the number of groupi=
ng paths as much as possible<br>while still achieving reasonable results.<b=
r><br>0006 builds grouped relations for each base relation if possible, and=
<br>generates aggregation paths for the grouped base relations.<br></div><d=
iv><br></div><div>0007 builds grouped relations for each just-processed joi=
n relation if<br>possible, and generates aggregation paths for the grouped =
join<br>relations.=C2=A0 The changes made to make_join_rel() are relatively=
 minor,<br>with the addition of a new function make_grouped_join_rel(), whi=
ch finds<br>or creates a grouped relation for the just-processed joinrel, a=
nd<br>generates grouped paths by joining a grouped input relation with a<br=
>non-grouped input relation.<br><br>The other way to generate grouped paths=
 is by adding sorted and hashed<br>partial aggregation paths on top of path=
s of the joinrel.=C2=A0 This occurs<br>in standard_join_search(), after we&=
#39;ve run set_cheapest() for the<br>joinrel.=C2=A0 The reason for performi=
ng this step after set_cheapest() is<br>that we need to know the joinrel=
9;s cheapest paths (see 0005).<br><br>This patch also makes the grouped rel=
ation for the topmost join rel act<br>as the upper rel representing the res=
ult of partial aggregation, so that<br>we can add the final aggregation on =
top of that.=C2=A0 Additionally, this<br>patch extends the functionality of=
 eager aggregation to work with<br>partitionwise join and geqo.<br><br>This=
 patch also makes eager aggregation work with outer joins.=C2=A0 With<br>ou=
ter join, the aggregate cannot be pushed down if any column referenced<br>b=
y grouping expressions or aggregate functions is nullable by an outer<br>jo=
in above the relation to which we want to apply the partiall<br>aggregation=
.=C2=A0 Thanks to Tom&#39;s outer-join-aware-Var infrastructure, we<br>can =
easily identify such situations and subsequently refrain from<br>pushing do=
wn the aggregates.<br><br>Starting from this patch, you should be able to s=
ee plans with eager<br>aggregation.<br><br>0008 adds test cases for eager a=
ggregation.<br><br>0009 adds a section in README that describes this featur=
e (copied from<br>previous patch set, with minor tweaks).<br><br>Thoughts a=
nd comments are welcome.<br></div><div><br></div><div>[1] <a href=3D"https:=
//www.vldb.org/conf/1995/P345.PDF" target=3D"_blank">https://www.vldb.org/c=
onf/1995/P345.PDF</a><br>[2] <a href=3D"https://www.postgresql.org/message-=
id/flat/9666.1491295317%40localhost" target=3D"_blank">https://www.postgres=
ql.org/message-id/flat/9666.1491295317%40localhost</a><br>[3] <a href=3D"ht=
tps://www.postgresql.org/message-id/flat/OS3PR01MB66609589B896FBDE190209F49=
5EE9%40OS3PR01MB6660.jpnprd01.prod.outlook.com" target=3D"_blank">https://w=
ww.postgresql.org/message-id/flat/OS3PR01MB66609589B896FBDE190209F495EE9%40=
OS3PR01MB6660.jpnprd01.prod.outlook.com</a><br><br>Thanks<br>Richard<br></d=
iv></div>
</blockquote></div>

--000000000000bc2c190652f6de50--