mikebridge commented on code in PR #44262:
URL: https://github.com/apache/superset/pull/44262#discussion_r4033213656
##########
superset/commands/deletion_retention/prune_audit.py:
##########
@@ -372,53 +457,105 @@ def _repeats_an_earlier_block(
survivor while its streak is current. It is also exempt from operational
age-out (see :func:`_operational_candidates`), so an operator force-purge
block is retained permanently — never pruned by either category.
+
+ P is the immediately preceding distinct blocked timestamp. A row repeats
+ only when P is in the current streak and both timestamp groups contain
+ solely its reason (including all-NULL groups). LAG over timestamp groups
+ supplies P and its reason counts without a group self-join. The sc-120493
+ PostgreSQL round-1 plan materialized a groups CTE and joined on entity
+ alone before filtering ranks, comparing 36 million row pairs.
+
+ Keep the repeat-id query uncorrelated: the sc-120493 Variant 2
+ measurements showed MySQL repeatedly executing
+ per-row predecessor scalars. During re-check, scope blocked rows, timestamp
+ groups and boundaries with literal entity-type and UUID lists from the
+ unlocked discovery. Their cross-product may include extra entity histories,
+ but candidacy remains restricted to the discovered ids and checked in SQL.
"""
- earlier: sa.FromClause = table.alias("earlier_block")
- between: sa.FromClause = table.alias("reason_change")
- reason_changed_between: sa.ColumnElement[bool] = sa.exists(
- sa.select(sa.literal(1))
- .select_from(between)
- .where(
- sa.and_(
- between.c.status == STATUS_BLOCKED,
- between.c.entity_type == table.c.entity_type,
- between.c.entity_uuid == table.c.entity_uuid,
- # Inclusive bounds: a differing-reason block sharing an
- # exact timestamp with either endpoint still breaks the run,
- # so a reason-transition row tied with a neighbour is
- # preserved as a run head rather than pruned as a repeat
- # (the same preserving-side tie rule the pending and evidence
- # guards use). Inclusive bounds only ever add boundaries —
- # i.e. only ever preserve more, never delete more.
- between.c.created_on >= earlier.c.created_on,
- between.c.created_on <= table.c.created_on,
- between.c.reason.is_distinct_from(table.c.reason),
- )
+ source: sa.Table = PurgeAuditLog.__table__
+ scope: list[sa.ColumnElement[bool]] = []
+ if scope_entities is not None:
+ types: list[str] = sorted({t for t, _ in scope_entities})
+ uuids: list[str] = sorted({u for _, u in scope_entities if u is not
None})
+ scope = [source.c.entity_type.in_(types),
source.c.entity_uuid.in_(uuids)]
Review Comment:
Good catch on the extra histories: this is a disclosed performance tradeoff,
not exact-pair scoping. At `db03401048de06282835bab5e86bf37db2f407ff`, the
scope helper documents the type/UUID cross-product; final locked candidacy is
still restricted to discovered IDs, and the shared-UUID/different-type
regression remains. Could we keep the ratified default50/max100 ceiling and
track plan improvements with Amin-owned #44349 rather than introducing another
predicate rewrite here? #44349 is downstream of this PR and needs to retain the
fallback, candidate gates and differential tests. No bounded lock-time or
production-capacity guarantee is claimed.
##########
superset/commands/deletion_retention/prune_audit.py:
##########
@@ -485,32 +665,33 @@ def _duplicate_candidates(now: datetime, limit: int) ->
sa.sql.Select:
"""
table: sa.Table = PurgeAuditLog.__table__
return (
- sa.select(table.c.id)
+ sa.select(table.c.id, table.c.entity_type, table.c.entity_uuid)
.where(*_duplicate_predicates(table, now))
.order_by(table.c.created_on)
.limit(limit)
Review Comment:
Agreed that LIMIT does not bound discovery's history work. The published
code explicitly describes the age-unbounded unlocked scan, and the
title/operator guidance no longer claim O(batch) or a short indexed window.
Could we retain this disclosed limitation for this scoped fix and coordinate
measured optimization with downstream #44349? Default50/max100 bounds the
candidate batch and placeholder budget, not discovery CPU or the scoped history
scanned during recheck. Live MySQL5.7/MariaDB validation and production
capacity remain unclaimed; no production sizing assumptions are inferred from
the synthetic measurements.
--
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]
