Project

General

Profile

Actions

Feature #23724

closed

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

Added by Oliver Hader over 13 years ago. Updated almost 9 years ago.

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

0%

Estimated time:
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)


Files

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

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Feature #23726: Refactor TCA definitions of table pagesClosedOliver Hader2010-10-14

Actions
Actions #1

Updated by Björn Pedersen over 13 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).

Actions #2

Updated by Björn Pedersen over 13 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. #

Actions #3

Updated by Oliver Hader over 13 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)...

Actions #4

Updated by Xavier Perseguers over 12 years ago

  • Category deleted (Communication)
  • Target version deleted (4.6.0-beta1)
Actions #5

Updated by Wouter Wolters over 9 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)?

Actions #6

Updated by Alexander Opitz almost 9 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.

Actions

Also available in: Atom PDF