As we merge with upstream and by that keep refining the Postgres
planner, legacy planner is no longer a suitable name. This changes
all variations of the spelling (legacy planner, legacy optimizer,
legacy query optimizer etc) to say "Postgres" rather than "legacy".
Reviewed-by: NVenkatesh Raghavan <vraghavan@pivotal.io>
Reviewed-by: NDavid Yozie <dyozie@pivotal.io>
Reviewed-by: NGeorgios Kokolatos <gkokolatos@pivotal.io>

In plans with a Nested Loop join on the inner side of another Nested Loop
join, the planner could produce a plan where a Motion node was rescanned.
That produced an error at execution time:

ERROR:  illegal rescan of motion node: invalid plan (nodeMotion.c:1604)  (seg0 slice4 127.0.0.1:40000 pid=27206) (nodeMotion.c:1604)
HINT:  Likely caused by bad NL-join, try setting enable_nestloop to off

Make sure we add a Materialize node to shield the from rescanning in such
cases.

While we're at it, add an explicit flag to MaterialPaths and plans, to
indicate that the Material node was added to shield the child node from
rescanning. There was a weaker test in ExecInitMaterial itself, which just
checked if the immediately child was a Motion node, but that feels
sketchy; what if there's a Result node in between, for example? However, I
kept the direct check for a Motion node, too, because I'm not sure if there
are other places where we add Material nodes on top of Motions, aside from
the call in create_nestloop_path() that this fixes. ORCA probably does
that, at least.

Fixes https://github.com/greenplum-db/gpdb/issues/6769Reviewed-by: NPengzhou Tang <ptang@pivotal.io>
Reviewed-by: NPaul Guo <pguo@pivotal.io>

We used to call some node types different names in EXPLAIN output,
depending on whether the plan was generated by ORCA or the Postgres
planner. Also, a Bitmap Heap Scan used to be called differently, when the
table was an AO or AOCS table, but only in planner-generated plans. There
was some historical justification for this, because they used to
be different executor node types, but commit db516347 removed last such
differences.

Full list of renames:

Table Scan -> Seq Scan
Append-only Scan -> Seq Scan
Append-only Columnar Scan -> Seq Scan
Dynamic Table Scan -> Dynamic Seq Scan
Bitmap Table Scan -> Bitmap Heap Scan
Bitmap Append-Only Row-Oriented Scan -> Bitmap Heap Scan
Bitmap Append-Only Column-Oriented Scan -> Bitmap Heap Scan
Dynamic Bitmap Table Scan -> Dynamic Bitmap Heap Scan

Also bump ORCA version to 3.4.0

Distribution key joins on pathkeys where the parser invokes an implicit
cast via a RelabelType node would introduce a redistribution motion due
to the join not being recognized as a colocated equijoin.

As an example, consider the following relation

    create table test (a varchar(10), b varchar(10)) distributed by (a);

The below query will introduce an implicit cast on a.a and b.a to TEXT by
the parser. This means that the pathkey EquivalenceClass is on VARCHAR but
the RestrictInfo ECs are for TEXT.

    select * from test a, test b where a.a=b.a;

Fix by following the EC members to their basetypes to allow for colocated
equijoins in these cases.

Affected testfiles updated, and one affected testcase slightly tweaked to
ignore less and generate less uninteresting output in the .out file.
Reviewed-by: NJesse Zhang <sbjesse@gmail.com>

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.

Signed-off-by: NJoao Pereira <jdealmeidapereira@pivotal.io>
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

The function `generate_implied_quals` was inferring quals and trying
to push them down inside the non Nullable side of the LEFT OUTER JOIN
and that behavior was incorrect. This was bubbling up in the following
error while trying to set join references(`set_join_references`):
`ERROR: variable not found in subplan target lists (setrefs.c:2085)`

This commit check if it is an outer join and if so will not try to infer
any predicates
Signed-off-by: NJoao Pereira <jdealmeidapereira@pivotal.io>

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

Prior to this commit, Orca returned wrong results for queries with left
outer joins containing predicates with `IS DISTINCT FROM`. This has been
fixed as part of ORCA v2.54.4.These are the associated tests.
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

Commit ce3153fa, about to be merged from PostgreSQL 9.0 soon, removes
the -w option from pg_regress's "diff" invocation. That commit will fix
all the PostgreSQL regression tests to pass without it, but we need to
also fix all the GPDB tests. That's what this commit does.

The different kinds of NOTICE messages regarding table distribution
were using a mix of upper and lower case for 'DISTRIBUTED BY'. Make
them consistent by using upper case for all messages and update the
test files, and atmsort regexes, to match.