Code RoomComposite index prefix match
EasyPrep Room Coding #4737

Composite index prefix match

CodingDatabases & SQLEntry–Mid~14 min

An orders table carries one composite index and the planner has to decide how much of it each query can use. index_columns lists the index columns in index order, outermost first, for example region then tier then created_at. Each entry of queries is the set of columns that query pins with an equality predicate, written as names joined by commas, for example "region,tier". Order inside a query carries no meaning because equality predicates commute, a name may repeat, and a name that is not an index column is ignored. The planner starts at the first index column and keeps going while the next index column is pinned. It stops at the first index column the query leaves unpinned, even when columns after that one are pinned. Return, for each query in order, how many leading index columns it can use.

Implement
usable_index_prefix(index_columns: list[str], queries: list[str]) → list[int]
Examples
in[["region","tier","created_at"],["region,tier","tier","region,created_at",""]]out[2,0,1,0]
in[["a","b","c"],["c,b,a","b,a"]]out[3,2]
in[["dept"],["dept,dept","status"]]out[1,0]
What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

0:00 of about 14 min
InputExpectedGot
[["region","tier","created_at"],["region,tier","tier","region,created_at",""]][2,0,1,0]not run yetsample
[["a","b","c"],["c,b,a","b,a"]][3,2]not run yetsample
[["dept"],["dept,dept","status"]][1,0]not run yetsample