Skip to content

Opening or closing a table built every shard and then dropped them - #522

Open
bjmeetsfo wants to merge 2 commits into
mainfrom
oss/open-close-table-skip-shard-list
Open

Opening or closing a table built every shard and then dropped them#522
bjmeetsfo wants to merge 2 commits into
mainfrom
oss/open-close-table-skip-shard-list

Conversation

@bjmeetsfo

Copy link
Copy Markdown
Collaborator

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:

shards OpenTable CloseTable
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.

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.

@bjmeetsfo
bjmeetsfo requested a review from superhaiou as a code owner August 31, 2026 11:44
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
bjmeetsfo force-pushed the oss/open-close-table-skip-shard-list branch from db7c0d6 to 9cd0fef Compare August 31, 2026 14:27
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.

2 participants