Skip to content

Extend transformed query reduction to DML - #1362

Closed
tlmorgan24 wants to merge 8 commits into
mainfrom
feature/query-reduction-extensions
Closed

tlmorgan24 wants to merge 8 commits into
mainfrom
feature/query-reduction-extensions

Conversation

@tlmorgan24

Copy link
Copy Markdown
Collaborator

The previously merged transformed query reduction (PR #1360) was for the EET SELECT oracle only. This extends the work to also benefit the EET DML oracle; the theoretical approach is the same (implementing the unchanged TransformationReproducer interface). The main difference is that a DML statement's transformable expressions vary by statement kind (e.g. UPDATE has SET values while DELETE does not), so much of the diff is to make the reproducer hold them in a fixed order with a reassembly function that rebuilds the statement string.

Other parts of the diff ensure the EET DML logs clearly lay out the reduction. A pre-existing bug is also solved, where any oracle supplying a reproducer would only report its findings when --use-reducer was enabled.

@tlmorgan24
tlmorgan24 requested a review from mrigger September 13, 2026 09:07
tlmorgan24 and others added 4 commits September 13, 2026 18:28
generateUnoptimizedQueryString projected COUNT(*) and cleared the WHERE
clause without re-projecting the predicate, so the unoptimized side
counted every row of the table regardless of the condition. Every run
whose predicate filtered anything therefore reported a mismatch.

Project the predicate per row instead, as the other NoREC generators do.
A CASE expression is used rather than a cast because HSQLDB does not
allow casting a BOOLEAN to an integer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01G1XqNaswnH8mWTXFkkGa1X
generateOptimizedQueryString projected a literal COUNT(*) column in its
non-aggregate branch as well as in its aggregate one. NoRECOracle counts
the rows that branch returns, and an aggregate always returns exactly
one, so the optimized count was 1 whatever the predicate matched.

Project * in the non-aggregate branch, as PostgresExpressionGenerator
does.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01G1XqNaswnH8mWTXFkkGa1X
generateOptimizedQueryString set the WHERE clause only in its
non-aggregate branch, so the aggregate branch counted every row of the
table while the unoptimized side applied the predicate.

Set the WHERE clause for both branches.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01G1XqNaswnH8mWTXFkkGa1X
The expression generator can produce chr() with a negative argument, on
which YSQL raises "character number must be positive". That error was
missing from YSQLErrors, so the oracle reported it as an unexpected
error rather than ignoring the statement.

PostgresCommon already lists it (PostgresCommon.java:87); YSQLErrors
otherwise mirrors that list.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01G1XqNaswnH8mWTXFkkGa1X
@tlmorgan24

Copy link
Copy Markdown
Collaborator Author

By solving the bug where an oracle would not report its findings, some pre-existing defects unrelated to my work were revealed in the CI tests. After fixing these too, the current PR is trying to accomplish too many things at once, so I am closing it and splitting it into two separate PRs.

@tlmorgan24 tlmorgan24 closed this Sep 13, 2026
@tlmorgan24
tlmorgan24 deleted the feature/query-reduction-extensions branch September 13, 2026 12:05
@tlmorgan24
tlmorgan24 removed the request for review from mrigger September 13, 2026 12:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant