Feature #23724

Optimize query to determine whether a frontend user has access to content elements or pages

Added by Oliver Hader about 9 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2010-10-14
Due date:
% Done:

0%

PHP Version:
5.2
Tags:
Complexity:
Sprint Focus:

Description

The WHERE part of the query to determine whether a frontend user has access to a particular element (tt_content in this example) looks like this:

(tt_content.fe_group='' OR tt_content.fe_group IS NULL OR tt_content.fe_group='0'
OR FIND_IN_SET('0',tt_content.fe_group)
OR FIND_IN_SET('-2',tt_content.fe_group)
OR FIND_IN_SET('2',tt_content.fe_group))

It could look like the following (to simplify the OR parts for each group):

(pages.fe_group='' OR pages.fe_group IS NULL OR pages.fe_group='0'
OR pages.uid IN (SELECT uid_local FROM pages_fe_groups_rel_mm WHERE uid_foreign IN (0,-2,2)))

(issue imported from #M15985)

0015985.patch View (12.1 KB) Administrator Admin, 2010-10-14 16:13


Related issues

Related to TYPO3 Core - Feature #23726: Refactor TCA definitions of table pages Closed 2010-10-14

History

#1 Updated by Björn Pedersen about 9 years ago

Be careful with subselects, mysql seems t have some performance problems:
http://bugs.mysql.com/bug.php?id=16159

See also http://bugs.typo3.org/view.php?id=15984 where this affects crawler (here up to 200 sec for a single update).

#2 Updated by Björn Pedersen about 9 years ago

from: http://dev.mysql.com/doc/refman/5.1/en/subquery-restrictions.html (same also for 5.5) #

Subquery optimization for IN is not as effective as for the = operator or for the IN operator.

A typical case for poor IN subquery performance is when the subquery returns a small number of rows but the outer query returns a large number of rows to be compared to the subquery result.

The problem is that, for a statement that uses an IN subquery, the optimizer rewrites it as a correlated subquery. Consider the following statement that uses an uncorrelated subquery:

SELECT ... FROM t1 WHERE t1.a IN (SELECT b FROM t2);

The optimizer rewrites the statement to a correlated subquery:

SELECT ... FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.b = t1.a);

If the inner and outer queries return M and N rows, respectively, the execution time becomes on the order of O(M×N), rather than O(M+N) as it would be for an uncorrelated subquery.

An implication is that an IN subquery can be much slower than a query written using an IN operator that lists the same values that the subquery would return. #

#3 Updated by Oliver Hader about 9 years ago

Thanks Björn for pointing this out. What would be alternatives in this case? Use separate queries? Or rewrite this part to use LEFT JOIN?

I just added the current version of the patch (without further optimization to the subqueries)...

#4 Updated by Xavier Perseguers over 8 years ago

  • Category deleted (Communication)
  • Target version deleted (4.6.0-beta1)

#5 Updated by Wouter Wolters almost 5 years ago

  • Status changed from New to Needs Feedback

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.2.9)?

#6 Updated by Alexander Opitz over 4 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Also available in: Atom PDF