yjhjstz commented on code in PR #2007:
URL: https://github.com/apache/cloudberry/pull/2007#discussion_r4031714807
##########
src/backend/gporca/libgpopt/src/engine/CStatisticsConfig.cpp:
##########
@@ -41,7 +41,7 @@ CStatisticsConfig::CStatisticsConfig(CMemoryPool *mp,
m_max_stats_buckets(max_stats_buckets),
m_phsmdidcolinfo(nullptr)
{
- GPOS_ASSERT(CDouble(0.0) < damping_factor_filter);
+ GPOS_ASSERT(CDouble(0.0) <= damping_factor_filter);
GPOS_ASSERT(CDouble(0.0) <= damping_factor_join);
GPOS_ASSERT(CDouble(0.0) < damping_factor_groupby);
Review Comment:
Same issue one line below: `optimizer_damping_factor_groupby` also has GUC
min `0.0` (guc_gp.c), but this assert is still strict. Verified on this patch:
`SET optimizer_damping_factor_groupby = 0; EXPLAIN SELECT a, b, count(*) FROM
damping_inner GROUP BY a, b;` still gives
```
INFO: GPORCA failed to produce a plan, falling back to Postgres-based
planner
DETAIL: CStatisticsConfig.cpp:46: Failed assertion: CDouble(0.0) <
damping_factor_groupby
```
The consumer (`CStatisticsUtils::GetCumulativeNDVs` ->
`DampedGroupByScaleFactor`) already clamps with `MinDistinct`, so `<=` should
be safe here as well.
##########
src/backend/gporca/libnaucrates/src/statistics/CScaleFactorUtils.cpp:
##########
@@ -502,12 +502,25 @@ CScaleFactorUtils::CalcScaleFactorCumulativeConj(
const ULONG num_cols = scale_factors->Size();
CDouble scale_factor(1.0);
+ if (0 == num_cols)
Review Comment:
Is this reachable? The only caller
(`CFilterStatsProcessor::MakeHistHashMapConjFilter`) unconditionally appends
`last_scale_factor` before calling, so `Size() >= 1`, and the pre-existing loop
already returned 1.0 for zero iterations. It seems to exist only to guard the
new `(*scale_factors)[0]` below. If the zero branch is kept, the sibling
`CalcScaleFactorCumulativeDisj` expresses the same precondition as
`GPOS_ASSERT(0 < num_cols)`, which may be the more consistent form.
##########
src/backend/gporca/libnaucrates/src/statistics/CScaleFactorUtils.cpp:
##########
@@ -502,12 +502,25 @@ CScaleFactorUtils::CalcScaleFactorCumulativeConj(
const ULONG num_cols = scale_factors->Size();
CDouble scale_factor(1.0);
+ if (0 == num_cols)
+ {
+ return scale_factor;
+ }
+
if (1 < num_cols)
{
// sort (in desc order) the scaling factor based on the
selectivity of each column
scale_factors->Sort(CScaleFactorUtils::DescendingOrderCmpFunc);
}
+ if (CDouble(0.0) == stats_config->DDampingFactorFilter())
Review Comment:
I believe this branch computes exactly what the loop below already computes
when the damping factor is 0, so it does not change behavior:
- `CDouble` clamps 0 to `GPOS_FP_ABS_MIN` (1e-250).
- `DampedFilterScaleFactor(cfg, 1)` returns 1.0, so the first term is
`max(MinRows, sf[0])`.
- For `ul >= 1`, `Pow(1e-250, n)` re-clamps to 1e-250; `sf * 1e-250 <= 1e250
* 1e-250 = 1`, so `max(MinRows=1.0, ...)` is 1.0 for every remaining term.
- Product = `max(1.0, sf[0])` -- identical to this return.
Empirically, `SET optimizer_damping_factor_filter = 1e-200` (old loop path)
and `= 0` (this branch) give bit-identical estimates on the test-plan tables
(AND: rows=334, OR: rows=835). So the comment's "rather than relying on
CDouble's minimum magnitude" describes a difference that does not materialize.
I would suggest dropping the branch (the assert change alone fixes the
fallback) or replacing it with a comment explaining why 0 degenerates to the
largest scale factor. Also note `CDouble::operator==` is itself a
1e-250-tolerance compare on clamped values, so the test does rely on the
minimum magnitude.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
