Repository navigation
[6.x] Skip empty-list lookups in the Entries fieldtype and Stache whereIn" - #15879
Merged
jasonvarga merged 6 commits intoNov 13, 2026
Merged
jasonvarga merged 6 commits into
jasonvarga merged 6 commits into
Conversation
A listing column for an entries field with nothing selected ran two queries across every collection for whereIn('id', []), which can't match. Nothing is looked for when nothing is selected, and a where in an empty list no longer tests every value in the index.
whereIn('id', [...]) tested every id in every collection to find one or two. An entry's key in its collection's id index is its id, so the ones asked for are picked out directly, in the order the index holds them. If any aren't found that way the query filters as before, since ids are compared without regard to case.
…y id" This reverts commit 2cb6038.
…ship-queries # Conflicts: # src/Fieldtypes/Entries.php # tests/Data/Entries/EntryQueryBuilderTest.php
jasonvarga
changed the title
jasonvarga
changed the title
Member
|
Since merging #15890, this PR's performance improvement benchmarks is probably less. Still merging anyway. |
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.
A listing column for an entries field runs two queries for every row, even when the row has nothing selected. The value becomes
whereIn('id', []), which can't match anything, but each of the two queries still tests every id in every collection before finding that out. On a listing where most rows leave the field empty, that is most of the request.Fieldtypes\Entries::getItemsForPreProcessIndex()returns an empty collection when nothing is selected, without building a query.Stache\Query\Builder::filterWhereIn()returns nothing for an empty list without testing each value. AnorWhereInwith an empty list still leaves the rest of the query alone, andwhereNotInis untouched.augment()is unchanged, so a template still gets a query builder for an empty field.Benchmark
Against
6.xat 9d20aef, PHP 8.5, file cache store. A Control Panel listing of 50 entries with an entries-field column, in a collection where 62 of the 64 entries have nothing selected. One PHP process per request, three rounds of ten, alternating.A listing whose rows all have something selected doesn't change.
Checked
Every page and Control Panel response of the benchmark site, the contents of 136 indexes and the ids returned by 44 queries are byte-identical to
6.x.The first change is in the fieldtype, so it applies whichever driver stores the entries. The second is the Stache's own builder.
Tests
idand for another field;orWhereInwith an empty list keeps what the first where found;whereNotInwith an empty list finds everything;nulland for[].They pass on
6.xwithout this change.