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>

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

In 8.4, a 'recheck' flag was added to TBMIterateResult. But the bitmap
AO table scan methods didn't get the memo. Because of that, they would
fail to recheck the original index quals, when the index operator was
lossy. Test case included to demonstrate the bug.

Unrelatedly, remove a FIXME comment about the need to have EvalPlanQual
recheck functions for bitmap AO table scans. That 'recheck' method is
in fact unnecessary for AO tables, as explained in the comment that
replaces the FIXME. This is confusing, so pay attention: the 'recheck'
functionality that this commit fixes, is unrelated to the FIXME comment
and the Recheck "access methods". But I found the bug with the
TBMIterateResult.recheck field when I started to look into that. I'm glad
I was confused about that myself, or I would not have tested the thing
that was actually broken :-)

As a side-note, it's confusing that we have essentially duplicated the
bitmap heap/AO/AOCS scan code so many times. We have Bitmap Table Scan for
heap, AO and AOCS tables, when ORCA is used. And separate Bitmap Heap Scan
and Bitmap AO/AOCS Scan nodes when the Postgres planner is used. We
should refactor that, but not in this patch.

Translate nestparams passed from ORCA to create the nestparams node in Nested Loop joins.

This feature can be enabled by setting the trace flag EopttraceEnableNestLoopParams.
Co-authored-by: NAbhijit Subramanya <asubramanya@pivotal.io>
Co-authored-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.

as same as upstream.

In upstream, internal_bpchar_pattern_compare compare inputs by ignoring
ending space. But GPDB it just use whole string compare. The bug didn't
appear because the before merging PG_MERGE_84 GPDB just use TableScan when executing
following query, but after PG_MERGE_84, IndexScan is used, and internal_bpchar_pattern_compare
will be used for index:
create table tbl(id int4, v char(10));
create index tbl_v_idx_bpchar on tbl using btree(v bpchar_pattern_ops);
insert into tbl values (1, 'abc');
explain select * from tbl where v = 'abc '::char(20);
select * from tbl where v = 'abc '::char(20);

Author: Xiaoran Wang <xiwang@pivotal.io>

Most of the code and test data in src/test/tinc/tincrepo/query/indexapply
was unused. AFAICS, only the two "mpp21852" tests were run. Move those
tests to the pg_regress regression suite.

In the updated tests, we used functions like disable_xform and
enable_xform to hint the optimizer to disallow/allow a particular
physical node. However, these functions are only available when GPDB
is built with GPORCA. Planner on the other hand accomplished this
via a GUC.

To avoid usage of these functions in tests, I have introduced couple
of GUCS that mimic the same planner behavior but now for GPORCA.
In this effort I needed to add an API inside GPORCA.

Currently, when the stats are not existing for a relation, planner
relies on default values instead of running pg_relation_size to save
time. However, this causes planner to produce bad plans. Earlier, the
code had the feature to collect stats for planner if the table did not
had any stats, but it was removed.

This fix re-introduces the feature with the GUC to control whether to use
default values or run pg_relation_size to get actual stats if stats are
not present. By default, the GUC is turned off.

[#129570829]

pg_regress uses gpdiff.pl to mask differences in costs etc. of EXPLAIN
output, so that trivial changes in the plan output don't cause a
regression failure. That mechanism didn't work for this EXPLAIN query,
because the "explain" and "select" were on different lines. Remove the
newline, to make gpdiff.pl recognize the query as an EXPLAIN query, to
make the test case less fragile.

Change behaviour to use default estimates for relation size
for cases when no statistics are available.

This avoid having heavy statstistics computation as part
of query compilation.

Customer can explicitly using ANALYZE to compute the stats
before running queries to use more accurate stats instead
of default statistics.

Currently, the default size of table is:
- Internal table: 100 pages
- External table: 1000 pages
Signed-off-by: NXin Zhang <xzhang@pivotal.io>