Bug #55180
closed
Epic #55070: Workpackages
Epic #55065: WP: Overall System Performance (Backend and Frontend)
Task #55179: Optimize SQL Performance
Increase Determination of siteroot page
100%
Description
TYPO3 detects the rootpage by issuing a where clause on the pages table:
Count: 786 Time=0.04s (35s) Lock=0.00s (0s) Rows=0.0 (0), webuser[webuser]@localhost
SELECT uid FROM pages WHERE deleted=N AND hidden=N AND is_siteroot=N LIMIT N
no index on is_siteroot and hidden.
Updated by Markus Klein almost 11 years ago
Hi Ingo.
Count: 786
Is that for one single FE/BE request??
Updated by Gerrit Code Review almost 11 years ago
- Status changed from New to Under Review
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27154
Updated by Gerrit Code Review almost 11 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27154
Updated by Ingo Schmitt almost 11 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 7a71192e02ac21d35866307a7876d9f0c58423b9.
Updated by Ingo Schmitt almost 11 years ago
- Estimated time changed from 0.50 h to 2.00 h
Updated by Christian Kuhn almost 10 years ago
Actually, this query is not fired this way at all!
the siteroot determination works by first finding the uid of the requested page, then getting its rootline, then iterating over it to see which of it has is_siteroot set.
where did this query actually came from, and which code part of the core fires it? i could not find anything like that, so imho the created index is bogus. if some extension (like TV) does stuff like that, it should add its index on its own.
... still investigating on this since i'm not 100% sure about those claims ... i woke up again on this topic because of pending patch https://review.typo3.org/#/c/31082/ which wants to change this index again (also for questionable reasons) ...
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed