You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Under stess testing the LastModified secondary index produces slower FIND_ITEMS results w/ higher Spanner CPU usage than not using it at all, specifically on larger result sets generated by the load tester.
FIND_ITEMS implicitly joins the index against the BSO table (to load columns not included in the index). Spanner's query planner produces a Cross Apply w/ an Input of the results of the index query and a Map on the bso table. Each Map produces an individual "execution" and each execution completes rather quickly, but on larger result sets begins to add up.
We can avoid all the individual executions by doing the index query first and passing its results to a separate query to load the other columns.
Let's add a flag to test this under load.
We should expect this secondary index to work more efficiently on typical FIND_ITEMS work loads producing a smaller number of results. The goal here is to utilize it for this sake while still producing reasonable response times/cpu usage with larger results as well.
The text was updated successfully, but these errors were encountered:
Under stess testing the LastModified secondary index produces slower FIND_ITEMS results w/ higher Spanner CPU usage than not using it at all, specifically on larger result sets generated by the load tester.
FIND_ITEMS implicitly joins the index against the BSO table (to load columns not included in the index). Spanner's query planner produces a Cross Apply w/ an Input of the results of the index query and a Map on the bso table. Each Map produces an individual "execution" and each execution completes rather quickly, but on larger result sets begins to add up.
We can avoid all the individual executions by doing the index query first and passing its results to a separate query to load the other columns.
Let's add a flag to test this under load.
We should expect this secondary index to work more efficiently on typical FIND_ITEMS work loads producing a smaller number of results. The goal here is to utilize it for this sake while still producing reasonable response times/cpu usage with larger results as well.
The text was updated successfully, but these errors were encountered: