Co-authored-by: NChris Hajas <chajas@pivotal.io>
Co-authored-by: NSambitesh Dash <sdash@pivotal.io>

We had changed this in GPDB, to print less parens. That's fine and dandy,
but it hardly seems worth it to carry a diff vs upstream for this. Which
format is better, is a matter of taste. The extra parens make some
expressions more clear, but OTOH, it's unnecessarily verbose for simple
expressions. Let's follow the upstream on this.

These changes were made to GPDB back in 2006, as part of backporting
to EXPLAIN-related patches from PostgreSQL 8.2. But I didn't see any
explanation for this particular change in output in that commit message.

It's nice to match upstream, to make merging easier. However, this won't
make much difference to that: almost all EXPLAIN plans in regression
tests are different from upstream anyway, because GPDB needs Motion nodes
for most queries. But every little helps.

In the Window functions rewrite, I had accidentally disabled the creation
of the multi-phase DQA plans. As a result, queries containing DISTINCT-
qualified aggregates, e.g. "SUM(DISTINCT n)", generated naive single-phase
plans, which can be much less efficient.

In PostgreSQL, DISTINCT aggregates are planned similarly to ordered
aggregates, using a tuplesort inside the Agg node. Because of that, the
AggClauseCosts.numOrderedAggs count includes both DISTINCT and ordered
aggregates. With cdb_grouping_planner, we fall back to that method for
ordered aggregates, but for DISTINCT aggregates, it can generate smarter
plans. However, because it was checking numOrderedAggs to check whether
the plan contained any, it got fooled and also fell back if there were any
DISTINCT aggregates. To fix, add a separate counter for true ordered
aggregates that doesn't include DISTINCTs.

The DQA-planner code had bitrotted somewhat, while it's not been used.
Nowadays, the Aggref.args list contains TargetEntrys instead of plain
expressions. And when constructing subqueries on the fly, the RelOptInfos
created for the RTE_SUBQUERY rtable entries need to have the 'subplan'
and 'subroot' fields filled in. Those changed were made to the similar code
for the normal, non-DISTINCT 2-phase aggs during the merges, but the
DQA code was neglected, because it was unused.

We have tests for DQAs, but apparently none of the tests use EXPLAIN, so
although you still got correct results, we did not notice that the plans
regressed. The expected output of a few existing EXPLAIN tests changes but
they were fairly simple cases where the naive plan actually seems fine as
well. Add EXPLAINs to a few queries in the gp_dqa test, so that we will be
alarmed if this happens again.

Fixes https://github.com/greenplum-db/gpdb/issues/5627

Among other things, this fixes the inaccuracy of integer avg() and sum()
functions. (i.e. fixes https://github.com/greenplum-db/gpdb/issues/5525)

The upstream versions are from PostgreSQL 9.6, using the 128-bit math
from the following commit:

commit 959277a4
Author: Andres Freund <andres@anarazel.de>
Date:   Fri Mar 20 10:26:17 2015 +0100

    Use 128-bit math to accelerate some aggregation functions.

    On platforms where we support 128bit integers, use them to implement
    faster transition functions for sum(int8), avg(int8),
    var_*(int2/int4),stdev_*(int2/int4). Where not supported continue to use
    numeric as a transition type.

    In some synthetic benchmarks this has been shown to provide significant
    speedups.

    Bumps catversion.

    Discussion: 544BB5F1.50709@proxel.se
    Author: Andreas Karlsson
    Reviewed-By: Peter Geoghegan, Petr Jelinek, Andres Freund,
        Oskari Saarenmaa, David Rowley

This is a partial backport of a larger body of work which also already have
been partially backported.

Remove the GPDB-specific "breadcrumbs" mechanism from the parser. It is
made obsolete by the upstream mechanism. We lose context information from
a few errors, which is unfortunate, but seems acceptable. Upstream doesn't
have context information for those errors either.

The backport was originally done by Daniel Gustafsson, on top of the
PostgreSQL 8.3 merge. I tweaked it to apply it to master, before the
merge.

Upstream commit:

  commit b153c092
  Author: Tom Lane <tgl@sss.pgh.pa.us>
  Date:   Mon Sep 1 20:42:46 2008 +0000

    Add a bunch of new error location reports to parse-analysis error messages.
    There are still some weak spots around JOIN USING and relation alias lists,
    but most errors reported within backend/parser/ now have locations.

This code and bug was in 1f4ad703, and it
caused an "operator XXX is not a valid ordering operator" error.

The 'sortop' field in SortClause and GroupClause needs to be an ordering
operator, i.e. the "<" operator, while we use the "=" operator to represent
grouping in other places. Need to be careful to convert between the two
in right places.

Add a few tests for this in the gp_dqa test case. This was reproducible by
the existing queries, when you coerce the planner to choose sort+group
aggregates instead of hash aggregates.