Add test case with ORCA query optimizer enabled

[edespino]

Adds test configuration for running regression tests with ORCA enabled:

• test: ic-good-opt-on
• make_configs: src/test/regress:installcheck-good
• pg_settings.optimizer: "on"

The ORCA query optimizer provides cost-based query optimization and offers additional query optimization capabilities. This configuration allows regression testing with ORCA enabled to verify optimizer functionality.

[my-ship-it]

Thanks @edespino for adding the ORCA test back, which provides a guarantee for our subsequent code merging

[edespino]

@my-ship-it I am afraid there is some flakiness in these tests. They do not run successfully all the time. Is anyone looking into this? Has the inconsistent orca configuration testing behavior been seen in the past? If I commit these like this, they could cause an issue for developers working on unrelated features yet these orca configured tests fail unexpectedly.

[edespino]

Initial test run failed. I am going to attempt to re-run:

Found regression.diffs at: ./src/test/regress/regression.diffs
diff -I HINT: -I CONTEXT: -I GP_IGNORE: -U3 /__w/cloudberry/cloudberry/src/test/regress/expected/bfv_meta_track.out /__w/cloudberry/cloudberry/src/test/regress/results/bfv_meta_track.out
--- /__w/cloudberry/cloudberry/src/test/regress/expected/bfv_meta_track.out	2024-12-19 00:51:37.42999[17](https://github.com/apache/cloudberry/actions/runs/12408761196/job/34641445868#step:18:18)54 -0800
+++ /__w/cloudberry/cloudberry/src/test/regress/results/bfv_meta_track.out	2024-12-19 00:51:37.433991716 -0800
@@ -19,7 +19,7 @@
 select count(*) from pg_stat_last_operation a join pg_policy b on b.oid = a.objid where b.polname = 'p1' and b.polrelid ='t1'::regclass::oid;
  count 
 -------
-     1
+     2
 (1 row)
 
 drop policy p1 on t1;

[edespino]

The second attempt to run ic-good-opt-on passed.

[edespino]

I am re-running all jobs again. I'm curious how often these tests are failing.

[my-ship-it]

@my-ship-it I am afraid there is some flakiness in these tests. They do not run successfully all the time. Is anyone looking into this? Has the inconsistent orca configuration testing behavior been seen in the past? If I commit these like this, they could cause an issue for developers working on unrelated features yet these orca configured tests fail unexpectedly.

@avamingli Mingli, could you please help continue to investigate on the flaky failure, thanks!

[avamingli]

@my-ship-it I am afraid there is some flakiness in these tests. They do not run successfully all the time. Is anyone looking into this? Has the inconsistent orca configuration testing behavior been seen in the past? If I commit these like this, they could cause an issue for developers working on unrelated features yet these orca configured tests fail unexpectedly.

@avamingli Mingli, could you please help continue to investigate on the flaky failure, thanks!

The problem has been blocking me for a while in another PR, and I currently have no idea how to resolve it. What we can confirm is that the flaky case is unrelated to this or any other PR. It seems quite odd since we only have one table in the schema of the test cases. We haven't encountered this flaky case until about one or two weeks ago.

Initially, I considered the possibility of multiple instances running queries, which might indicate a concurrency issue. However, after syncing with Ed, he confirmed that the test groups run independently.

We could create an issue for this, but I'm unsure how to proceed at the moment.
@weinan003 suggest modifying the test cases to include SELECT xmin to check if the differences are caused by different transactions. I think it's a good idea, and I plan to implement it after my vacation. At the very least, it could represent a small step forward.