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
Added by Ingo Schmitt over 10 years ago.
Updated over 6 years ago.
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.
Hi Ingo.
Count: 786
Is that for one single FE/BE request??
- Category set to Performance
- Status changed from New to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Estimated time changed from 0.50 h to 2.00 h
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) ...
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by