Opening or closing a table built every shard and then dropped them - #522
Open
bjmeetsfo wants to merge 2 commits into
Open
Opening or closing a table built every shard and then dropped them#522bjmeetsfo wants to merge 2 commits into
bjmeetsfo wants to merge 2 commits into
Conversation
Opening a table reads one number out of the answer -- the version a caller
must quote to be given a topology. Closing one reads only whether the table
could be served at all. Both asked for the whole topology, so both paid to
build a shard list that neither looked at, and the cost was the size of the
table:
open close
50 28.9us 31.5us
200 114.6us 113.6us
800 434.9us 435.7us
Now 0.5us at every one of them, and flat rather than growing with the table.
The cheap answer already existed inside the same call. A caller that is
already current is given the status and the table and stops before the shard
list is built, and every missing, dropped and frozen check -- including the
namespace ones -- runs before that point. So this asks for the topology with
the version set past anything a table can hold, rather than repeating those
checks somewhere new where they could drift from the originals. The status
these routes report is the same status because it is the same code producing
it.
Nothing observable changes. Opening reads the version, which the early answer
carries; closing reads the status, which is identical in every case; neither
route exposes the flag that says the answer was unchanged.
Neither route had a test. They have one now, covering the version, the
refusals for a table that was never created and for one that has been
dropped, and a check that the cheap answer carries no shards while the full
one still carries four -- so the saving is asserted by counting what was
built rather than by timing it.
Both tests were checked against a mutation: made to build the shard list
again, and made to report the version as zero. Each fails.
Measured with the arms interleaved on a shared box.
bjmeetsfo
force-pushed
the
oss/open-close-table-skip-shard-list
branch
from
August 31, 2026 14:27
db7c0d6 to
9cd0fef
Compare
…e-skip-shard-list
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
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.
Opening a table reads one number out of the answer -- the version a caller must quote to be given a topology. Closing one reads only whether the table could be served at all. Both asked for the whole topology, so both paid to build a shard list that neither looked at, and the cost was the size of the table:
Now 0.5us at every one of them, and flat rather than growing with the table.
Why it is written this way
The cheap answer already existed inside the same call. A caller that is already current is given the status and the table back and stops before the shard list is built, and every missing, dropped and frozen check -- including the namespace ones -- runs before that point.
So this asks for the topology with the version set past anything a table can hold, rather than repeating those checks somewhere new where they could drift from the originals. The status these routes report is the same status because it is the same code producing it.
Nothing observable changes
Opening reads the version, which the early answer carries. Closing reads the status, which is identical in every case. Neither route exposes the flag that says the answer was unchanged.
The route just below these two, which serves topologies to proxies, was already passing the caller's version through and is untouched.
Testing
Neither route had a test. They have one now, covering the version, the refusals for a table that was never created and for one that has been dropped.
There is also a test that the cheap answer agrees with the full one on status and version across a normal table, a frozen table, a dropped table, a table in a frozen namespace, and two that do not exist -- and that it carries no shards while the full answer still carries four. The saving is asserted by counting what was built rather than by timing it, so it holds on a loaded machine.
Both tests were checked against a mutation: made to build the shard list again, and made to report the version as zero. Each fails.
Measurements were taken with the arms interleaved, because the box is shared.
Suites: 327 metadata tests and 48 metaserver binary tests, all green.