Flatten index to remove expensive joins during invalidation #2003
Conversation
| test('can get paginated results that are stable during index mutations', async function (assert) { | ||
| await runSharedTest(indexQueryEngineTests, assert, { | ||
| indexQueryEngine, | ||
| dbAdapter, | ||
| loader, | ||
| testCards, | ||
| }); | ||
| }); | ||
|
|
There was a problem hiding this comment.
when ed ad I reviewed this he felt that this was actually a weird feature in that this means that as you paginate the search results you are not necessarily seeing the latest query results since we are trying to maintain the results from when you originally made the request as you paginate thru the results as opposed to showing the latest values.
| @@ -48,14 +48,6 @@ module('Unit | index-writer', function (hooks) { | |||
| }); | |||
| }); | |||
|
|
|||
| test('only invalidates latest version of content', async function (assert) { | |||
There was a problem hiding this comment.
this becomes moot since we are now breaking out the working version and the production version into separate tables
| // TODO: If this query is still slow we'll need to consider dropping | ||
| // this join and writing a pg specific query here--as this query is | ||
| // currently written in a less performant manner in order to be | ||
| // compatible with SQLite. make sure to measure performance in hosted | ||
| // env first before sending for team review. Should strive to be less | ||
| // than 50ms (currently about 600-700ms) when this is run against a | ||
| // reasonably sized index. |
There was a problem hiding this comment.
we should really just do this
Host Test Results 1 files ±0 1 suites ±0 21m 7s ⏱️ -39s Results for commit 87ef92c. ± Comparison against base commit 1353a82. This pull request removes 2 tests.♻️ This comment has been updated with latest results. |
…ction-index-db-requests
This PR flattens our index so that remove the expensive join that was required to determine the index records that pertain to the current realm version. Instead of using a single table to control both the "production" index and the "working" index (the index that is being built), we use 2 tables. One table,
boxel_index_working, is just for building the index for each mutation, and the other table,boxel_index, is for querying the final version of the index.TODO:
boxel_index.icon_htmlcolumn from Show card type icon of CardsGird's filter list #1971