Problem/Motivation
Looking through the queries of my performance tests, I noticed that we seem to be querying the file_managed table twice, once with a wildcard for all fields, once with all fields listed explicitly.
For example: In \Drupal\Tests\demo_umami\FunctionalJavascript\OpenTelemetryNodePagePerformanceTest::testNodePageWarmCache for example.
'SELECT "base"."fid" AS "fid", "base"."uuid" AS "uuid", "base"."langcode" AS "langcode", "base"."uid" AS "uid", "base"."filename" AS "filename", "base"."uri" AS "uri", "base"."filemime" AS "filemime", "base"."filesize" AS "filesize", "base"."status" AS "status", "base"."created" AS "created", "base"."changed" AS "changed" FROM "file_managed" "base" WHERE "base"."fid" IN (1)',
'SELECT "file_managed".*, "file_managed"."langcode" AS "file_managed__langcode" FROM "file_managed" "file_managed" WHERE "file_managed"."fid" IN (1)',
The first call happens directly in \Drupal\Core\Entity\Sql\SqlContentEntityStorage::getFromStorage() through buildQuery().
The second is in \Drupal\Core\Entity\Sql\SqlContentEntityStorage::loadFromDedicatedTables().
I think this is a side effect of the merged query for the configurable, but if there are none of those, then this query doesn't seem to do anything useful.
What I notice is that $chunks is a nested empty array, [0 => []], so it does the loop with nothing. But we can't just skip that as it might contain revision/data. Maybe we can check for those skip if we don't have any of that?
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3608374
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
berdirLets see what the tests think about this.
This saves 12/14 queries for my performance test on cold/cool caches (265 -> 251, 198 -> 186)
Comment #4
berdirSaves 6-7 queries on the umami performance tests too, no other test fails except the performance tests.
Comment #5
catchThis looks great. Approaching 10% query reduction on the lighter pages.
Comment #8
godotislateCommitted 98c10fd and pushed to main.
There's a merge conflict in 11.x, presumably in the performance test numbers, so we'll need an 11.x MR.
Also, I think this is good for backport to 11.4.x as well, but will confirm.
Comment #9
godotislateComment #10
catchI think this will be fine for an 11.4.x commit, no logic changes at all.
Comment #12
berdirRebased, query counts on the performance tests are the same, it just conflicted on the differences in context (the cache get/sets)
Comment #13
godotislateThere was a test failure, but I think it's intermittent because I've seen it fail a few times the last couple days, so re-running. Will add to the known list of flaky tests if so.
Comment #14
berdirGreen now, yes I think I've seen that a few times.
Comment #18
godotislateCommitted and pushed 978748d to 11.x and 4d79b69 to 11.4.x. Thanks!
Comment #20
godotislateCreated #3608805: [random test failure] Drupal\Tests\config\Functional\ConfigInstallProfileOverrideTest::testInstallProfileConfigOverwrite and added to #2829040: [meta] Known intermittent, random, and environment-specific test failures.