Relation metadata reference was added twice due to which
memory leak is detected and PQO fallsback to planner. This patch
removes redundant AddRef for Relation Metadata and fixes fallback.
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

These are the changes required to accommodate ORCA changes from PR:
https://github.com/greenplum-db/gporca/pull/159

Bumps up ORCA version to v2.29.0
Signed-off-by: NJemish Patel <jpatel@pivotal.io>

Bump orca version to 2.28.0
Signed-off-by: NJemish Patel <jpatel@pivotal.io>

It's not necessary to clear the error buffer on every call. Also,
GPOS_NEW_ARRAY() is a pretty slow way of clearing memory. This greatly
reduces the overhead of planning simple queries with ORCA.

On my laptop, this reduces the time for planning "SELECT 123;" from
about 60 ms to 5 ms.

These warnings are not enabled by default, but you'll see them with -Wall.

Added a guc, `optimizer_penalize_broadcast_threshold` to set the threshold on
maximum number of rows to broadcast.
Signed-off-by: NOmer Arap <oarap@pivotal.io>

This guc allow us to change the cost of sort and tuning the query plan
generated by Orca for better performance.

It was somewhat broken. The order of evaluation of function arguments is
implementation-specific, so in a statement like:

ereport(ERROR,
        (errcode(ERRCODE_INTERNAL_ERROR),
	 errOmitLocation(true)));

We cannot assume that errOmitLocation() is evaluated after errcode(). If
errOmitLocation() is evaluated first, the errcode() call could overwrite
the omit_location field, seeing that the error code was "internal error".

Almost all of the errOmitLocation calls in the codebase were superfluous
anyway. The default logic is to omit the location for anything else than
ERRCODE_INTERNAL error, so it is not necessary to call errOmitLocation(true),
if errcode (other than ERRCODE_INTERNAL_ERROR) is given. Likewise
errOmitLocation(false) is not needed for internal errors.

Remove the whole errOmitLocation() function. It's not really needed. The
most notable callsite where it mattered was in cdbdisp.c, but that one
was broken by the order-of-evaluation issue. Use a different error code
there. What we really should do there is to pass the error code from the
segment back to the client, but I'll leave that for another day.

Commit 38686122 changed the function to not give a WARNING, but neglected
the comment that says it does.

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

- In ORCA, due to the way exception handled previously we do warning first
and then later print error referring that message. In this commit, we
enhanced the exception handling so we just print a single error message.
- Also, we removed 'PQO unable to generate a plan' or 'Aborting PQO plan
generation' message and make the error message as close as the planner.
- Updated error message with filename and line number from where the exception
is raised.

libgpos has a set of banned API calls which needs to be allowed with
the ALLOW_xxx macro in order for gpopt to compile (and thus run).
The changes to ereport() brought a need for allowing abort() since
it now invokes abort when building with --enable-cassert.

This is a temporary fix awaiting the removal of the banning of
function calls entirely. Pushed even though the CI pipeline failed
to provide a clean run (for seeminly unrelated reasons) due to the
absence of this blocking other efforts.

* Fixing DXL Translator bug where we lose canSetTag during Query object mutation and the translator ends up using wrong canSetTag.

* Adding ICG test for verifying the the ORCA translator uses correct canSetTag.

* Preventing multiple ResLockPortal calls for the same portal when running multiple queries via PortalRunMulti by correctly populating canSetTag in PlannedStmt from Query object during DXL to PlannedStmt translation.

* ICG tests for checking if ORCA correctly populates canSetTag.

Any GPDB exception happens in while ORCA generating plan will abort
query.
Signed-off-by: NFoyzur Rahman <frahman@gmail.com>

This GUC will be used to control the MEMO size as well as optimization
time for large IN list or large array comparison expressions.

Only the Array with less number of elements than the GUC will be
expanded and participate in constraint derivation.

Trade-off of using this GUC is loss of potential benefits from the
constraint derivation (e.g. conflict detection, partition elimination)
with shorter optimization time and less memory utilization.

`set optimizer_join_arity_for_associativity_commutativity=7` will hint
at the optimizer to stop exploring join associativity and join
commutativity transformations when an n-ary join operator has more than
7 children during optimization, pruning quite a bit of the search space.

The 1.622 updates in b3668c40 adds
a depedency on CHint without adding the required header file to
build without warnings/errors.

This reverts commit f3134604.

Renaming optimizer_release_mdcache to a more intuitive name: optimizer_metadata_caching. Before this commit, we were caching metadata in optimizer side by setting optimizer_release_mdcache = OFF. Now, we cache metadata in optimizer side by setting optimizer_metadata_caching=ON.

ORCA uses its own metadata cache to store information about relations,
operators etc. Currently, we always reset the cache when planning a query,
unless the optimizer_release_mdcache GUC is turned off, which is slow.

To make it safe to turn optimizer_release_mdcache off, use the catalog
cache invalidation mechanism to still reset the cache when there are
changes to the catalogs that affect the metadata cache.

The ORCA-facing interface of this is the same as in the previous attempt:
A function that returns true/false indicating whether there has been any
catalog changes whatsoever since last call.

This reverts commit 6c31a3b4. Per
discussion, we will implement the same functionality in a simpler way.

Added a generation-based Metadata Versioning mechanism
which will be used by ORCA to cache and invalidate catalog
data in its Metadata Cache.
Versioning is disabled by default at this point, until the
Metadata Cache eviction policy is completed.

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