Conversation
…hen an index is unsampled records_in_range now probes tidesdb_range_stats over [value, successor(value)) for a point equality on a non-unique index with no cached sample, so a never-analyzed low-cardinality index estimates correctly from metadata instead of the records/10 fallback that reads one row per value and drives a full scan. unique, primary-key, and already-sampled indexes keep the cheap cached rec_per_key, so the sampled path is unchanged and points/ranges do not regress. adds rir_prefix_successor, updates the optimizer doc and the index_stats test to the improved before-analyze estimate.
a multi-row DELETE that removes every row across a contiguous primary-key span now writes one range tombstone instead of a per-row tombstone for each key. delete_row buffers each primary-row data key and holds its tombstone back; end_bulk_delete counts the live rows thetouched [min, max] span still holds and, when that equals the buffered count so the statement removed the whole span, issues one tidesdb_txn_delete_range. a survivor from aresidual filter, an IN-list gap, an ICP rejection, or an ORDER BY LIMIT leaves more live rows than buffered keys and falls back to per-row tombstones, so the result never changes. advertises HA_CAN_FORCE_BULK_DELETE so the server drives start_bulk_delete for a single-table delete, which also activates the existing compact-after-range-delete path. deferral is skipped for a table with a delete trigger and under galera, rows than buffered keys and falls back to per-row tombstones, so the result never changes. advertises HA_CAN_FORCE_BULK_DELETE so the server drives start_bulk_delete for a single-table delete, which also activates the existing compact-after-range-delete path. deferral is skipped for a table with a delete trigger and under galera, secondary-index entries are still deleted per row, a delete past a cap flushes to per-row tombstones, and the range tombstone carries the library's own OCC conflict detection. on a pk-only table a 200k-row range delete drops from ~0.33s to 0.192s and from 2.6MB of tombstone writes to essentially none. adds tidesdb_range_delete covering clean ranges, gaps, residual filters, LIMIT, rollback, secondary indexes, and triggers.
the analyze table diagnostic prints a write-amplification note whose wal byte count and derived ratio drift run to run from wal framing, so any test that records analyze output flakes under heavy parallel load.tidesdb_index_stats and tidesdb_analyze already normalize these figures with replace_regex, but tidesdb_row_cardinality recorded them verbatim and so failed intermittently on a wal= mismatch.apply the same mask before each analyze and keep asserting the real row counts through information_schema.TABLES, which is what the test is actually about. tidesdb_tpcc_contention, flagged alongside this, was investigated and left unchanged.its retry loop, its 1180/1213/1205 conflict handler, and the commit path are all correct, and no lost or double increment reproduced across roughly six hundred executions including two hundred under amplified sixteen-way contention with forced memtable backpressure, so its single earlier failure reads as an environmental blip rather than a logic defect.
the neword_incr retry loop gave up an increment under disk pressure.a losing optimistic attempt rolls back without an fsync, so it can spin through the whole thousand-try bound while the winning connections are still fsyncing their commits under full sync mode, then exit having never committed.the district counter then lands one short and the test fails on a 5004 against 5005. add a short randomized sleep after a conflicting attempt rolls back, the same way a real tpc-c client backs off, so the contention drains before the next try and every increment lands.the asserted counts are unchanged.reproduced reliably by running the storm under background disk io load, where an unfixed sixteen-way amplifier failed a hundred of a hundred and twenty runs and the backoff took it to a hundred and twenty of a hundred and twenty.
… for mariadb pick up
…fault table creation may fail with warning, this i documented
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.