The canonical config file is in src/backend/gpopt/.clang-format (instead
of under the non-existent src/backend/gporca), I've created one (instead
of two) symlink, for GPOPT headers. Care has been taken to repoint the
symlink to the canonical config under gpopt, instead of gpopt as it is
under HEAD.

This is spiritually a cherry-pick of commit 2f7dd76c.
(cherry picked from commit 2f7dd76c)

This commit enables the MCVs for text related types such as varchar, name etc
to be passed to ORCA so that it can estimate the cardinalities for columns
containing text related types. Prior to this commit, ORCA would estimate the
cardinality to be 40% of the tuples which would cause mis-estimation for
certain queries.
Co-authored-by: NAbhijit Subramanya <asubramanya@pivotal.io>
Co-authored-by: NShreedhar Hardikar <shardikar@pivotal.io>

GPORCA PR https://github.com/greenplum-db/gporca/pull/475 will remove
CDXLDatum::IsPassByValue() method and related code, because it's not
really needed and bloats DXL files unnecessarily. This commit makes the
corresponding changes to the GPORCA translator code.

Previously we would not pass the statistics for UUID columns to ORCA. This
would cause cardinality mis-estimation and hence would cause ORCA to pick a bad
plan. This patch fixes the issue by passing in the statistics for UUID columns.

The IMemoryPool interface was removed in ORCA to remove an unnecessary
abstraction layer and avoid costly casting.

Corresponding ORCA commit: e64a2b42

Bumps ORCA version to 3.46.0
Authored-by: NChris Hajas <chajas@pivotal.io>

Prior to this patch, the MCVs for text columns was not being passed to ORCA.
Hence the cardinality estimation for predicates involving text was inaccurate
and led to sub optimal plans being picked. This patch allows the MCVs to be
passed in to ORCA so that it can now estimate the cardinality using MCVs equal
and not equal operators for text columns.
Co-authored-by: NAbhijit Subramanya <asubramanya@pivotal.io>
Co-authored-by: NBhuvnesh Chaudhary <bchaudhary@pivotal.io>

As part of moving away from Hungarian notation in the GPORCA codebase,
the integration points between GPORCA and GPDB in the translator have
been renamed to the new convention used in GPORCA. The libraries
currently updated to the new notation in GPORCA are Naucrates and GPOS.
The new naming convention is a custom version of common C++ naming
conventions. The style guide for this convention can be found in the
GPORCA repository.

Also bump ORCA version to 2.69.0
Co-authored-by: NShreedhar Hardikar <shardikar@pivotal.io>
Co-authored-by: NMelanie Plageman <mplageman@pivotal.io>
Co-authored-by: NEkta Khanna <ekhanna@pivotal.io>
Co-authored-by: NAbhijit Subramanya <asubramanya@pivotal.io>
Co-authored-by: NSambitesh Dash <sdash@pivotal.io&gt;&lt;Paste>
Co-authored-by: NDhanashree Kashid <dkashid@pivotal.io>
Co-authored-by: NOmer Arap <oarap@pivotal.io>

Signed-off-by: NJesse Zhang <sbjesse@gmail.com>
(cherry picked from commit 16d53f26)

ORCA has historically ignored type modifiers from databases that support
them, noticeably Postgres and Greenplum. This has led to surprises in a
few cases:

1. The output description over the wire (for Postgres protocol) will
lose the type modifier information, which often meant length. This
surprises code that expects a non-default type modifier, e.g. a JDBC
driver.

2. The executor in some cases -- notably DML -- expects a precise type
modifier. Because ORCA always erases the type modifiers and presents a
default, the executor is forced to find that information elsewhere.

After this commit, ORCA will be aware of type modifiers in table
columns, scalar identifiers, constants, and length-coercion casts.
Signed-off-by: NShreedhar Hardikar <shardikar@pivotal.io>
(cherry picked from commit 2d907526)

This information can be easily derived from CDXLColRef member of
CDXLScalarIdent. This now mirrors what is done in the ORCA types
CScalarIdent and CColRef.
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

Corresponding gporca PR: greenplum-db/gporca#287

With commit 0daa3b5e, we consumed
winagg and winstar fields of WindowRef in ORCA. However, we don't
have the winagg and winstar fields yet available in WindowRef node.
Hence, marking as false.
Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>

With commit 387c485d winstar and winagg
fields were added in WindowRef Node, so this commit adds handling for
them in ORCA Translator.

The winlevelsup field isn't used. The reason it's not needed can be summed
up by this comment in PostgreSQL 8.4's transformWindowFunc function:

>  * Unlike aggregates, only the most closely nested pstate level need be
>  * considered --- there are no "outer window functions" per SQL spec.

Second line of reasoning is that the winlevelsup field was always
initialized to 0, and only incremented in the IncrementVarSublevelsUp
function. But that function is only used during planning, so winlevelsup
was always 0 in the parse and parse analysis stage. However, the field was
read only in the parse analysis phase, which means that it was always 0
when it was read.

Third line of reasoning is that the regression tests are happy without it,
and there was a check in the ORCA translator too, that would've thrown
an error if it was ever non-zero.

I left the field in place in the struct, to avoid a catalog change, but it
is now unsued. WindowRef nodes can be stored in catalogs, as part of views,
I believe.

Static variables when used inside function are initialized only once and stored
on static storage area. The original code without static initializes these
variables every time the function is called and these variables are stored in
stack. Since we don't change the array value, they can be static const.

ORCA can do some optimizations - partition pruning at least - if it can
"see" into the elements of an array in a ScalarArrayOpExpr. For example, if
you have a qual like "column IN (1, 2, 3)", and the table is partitioned on
column, it can eliminate partitions that don't hold those values. The
IN-clause is converted into an ScalarArrayOpExpr, so that is really
equivalent to "column = ANY <array>"

However, ORCA doesn't know how to extract elements from an array-typed
Const, so it can only do that if the array in the ScalarArrayOpExpr is
an ArrayExpr. Normally, eval_const_expressions() simplifies any ArrayExprs
into Const, if all the elements are constants, but we had disabled that
when ORCA was used, to keep the ArrayExprs visible to it.

There are a couple of reasons why that was not a very good solution. First,
while we refrain from converting an ArrayExpr to an array Const, it doesn't
help if the argument was an array Const to begin with. The "x IN (1,2,3)"
construct is converted to an ArrayExpr by the parser, but we would miss the
opportunity if it's written as "x = ANY ('{1,2,3}'::int[])" instead.
Secondly, by not simplifying the ArrayExpr, we miss the opportunity to
simplify the expression further. For example, if you have a qual like
"1 IN (1,2)", we can evaluate that completely at plan time to 'true', but
we would not do that with ORCA because the ArrayExpr was not simplified.

To be able to also optimize those cases, and to slighty reduce our diff
vs upstream in clauses.c, always simplify ArrayExprs to Consts, when
possible. To compensate, so that ORCA still sees ArrayExprs rather than
array Consts (in those cases where it matters), when a ScalarArrayOpExpr
is handed over to ORCA, we check if the argument array is a Const, and
convert it (back) to an ArrayExpr if it is.
Signed-off-by: NJemish Patel <jpatel@pivotal.io>

Signed-off-by: NXin Zhang <xzhang@pivotal.io>

I removed the 'pplstmt' argument in commit 413cb592, because all the
callers passed NULL. But missed this assertion that still referenced it.
Remove it, too.

Per off-list report by Haisheng Yuan.

A bunch of functions and classes that are not used anywhere.

gporca has a set of banned API calls which needs to be allowed with the
ALLOW_xxx macro in order for gpopt to compile. But it should be the
library caller(GPDB/Orca)'s resposibility to take care of the function call.

see discussions on greenplum-db/gpdb#1136
and https://groups.google.com/a/greenplum.org/forum/#!topic/gpdb-dev/Mcw6JPav6h4

Orca translator changes reorder include statements so that system and
PostgreSQL headers are grouped at the top.  Including such headers
within a C++ namespace causes compilation to fail with the new GCC.

The gpmonlib change removes inline keyword.  The new compiler is not
happy with inlining a function defined in an external object.

This is mostly copy-pasted from CoerceToDomain.

Note: This requires an up-to-date version of ORCA to compile, older
versions of the ORCA library itself don't know about CoerceViaIO nodes
either.

This commit eliminates the global new/delete overrides that were causing
compatibility problems (the Allocators.(h/cpp/inl) files have been
completely removed). The GPOS `New()` macro is retained and works the
same way, but has been renamed `GPOS_NEW()` to avoid confusion and
possible name collisions. `GPOS_NEW()` works only for allocating
singleton objects. For allocating arrays, `GPOS_NEW_ARRAY()` is
provided. Because we no longer override the global delete,
objects/arrays allocated by `GPOS_NEW()` and `GPOS_NEW_ARRAY()` must now
be deleted by the new functions `GPOS_DELETE()` and
`GPOS_DELETE_ARRAY()` respectively. All code in GPOS has been
retrofitted for these changes, but Orca and other code that depends on
GPOS should also be changed.

Note that `GPOS_NEW()` and `GPOS_NEW_ARRAY()` should both be
exception-safe and not leak memory when a constructor throws.

Closes #166