Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow query on where clause in composite primary key #8332

Closed
timsehn opened this issue Sep 4, 2024 · 2 comments
Closed

Slow query on where clause in composite primary key #8332

timsehn opened this issue Sep 4, 2024 · 2 comments
Labels
bug Something isn't working performance sql Issue with SQL

Comments

@timsehn
Copy link
Contributor

timsehn commented Sep 4, 2024

Database: https://www.dolthub.com/repositories/timsehn/media_wiki

Query:

SELECT /* MediaWiki\\Deferred\\LinksUpdate\\LinksTable::fetchExistingRows */ pp_propname,pp_value FROM `page_props` WHERE pp_page = 4003405
               -> ;
Empty set (317.22 sec)

Schema:

CREATE TABLE `page_props` (
  `pp_page` int unsigned NOT NULL,
  `pp_propname` varbinary(60) NOT NULL,
  `pp_value` blob NOT NULL,
  `pp_sortkey` float DEFAULT NULL,
  PRIMARY KEY (`pp_page`,`pp_propname`),
  UNIQUE KEY `pp_propname_page` (`pp_propname`,`pp_page`),
  UNIQUE KEY `pp_propname_sortkey_page` (`pp_propname`,`pp_sortkey`,`pp_page`)
) ENGINE=InnoDB DEFAULT CHARSET=binary COLLATE=binary

Weirdly, even explain on this one is slow indicating it may be a bug in analysis:

media_wiki/main*> explain SELECT /* MediaWiki\\Deferred\\LinksUpdate\\LinksTable::fetchExistingRows */ pp_propname,pp_value FROM `page_props` WHERE pp_page = 4003405 ;
+------------------------------------------------------------+
| plan                                                       |
+------------------------------------------------------------+
| Project                                                    |
|  ├─ columns: [page_props.pp_propname, page_props.pp_value] |
|  └─ IndexedTableAccess(page_props)                         |
|      ├─ index: [page_props.pp_page,page_props.pp_propname] |
|      ├─ filters: [{[4003405, 4003405], [NULL, ∞)}]         |
|      └─ columns: [pp_page pp_propname pp_value]            |
+------------------------------------------------------------+
6 rows in set (310.19 sec)
@timsehn
Copy link
Contributor Author

timsehn commented Sep 4, 2024

Subsequent runs of analyse returned fast:

media_wiki/main*> explain SELECT /* MediaWiki\\Deferred\\LinksUpdate\\LinksTable::fetchExistingRows */ pp_propname,pp_value FROM `page_props` WHERE pp_page = 4003405 ;
+------------------------------------------------------------+
| plan                                                       |
+------------------------------------------------------------+
| Project                                                    |
|  ├─ columns: [page_props.pp_propname, page_props.pp_value] |
|  └─ IndexedTableAccess(page_props)                         |
|      ├─ index: [page_props.pp_page,page_props.pp_propname] |
|      ├─ filters: [{[4003405, 4003405], [NULL, ∞)}]         |
|      └─ columns: [pp_page pp_propname pp_value]            |
+------------------------------------------------------------+
6 rows in set (0.00 sec)

@timsehn timsehn added bug Something isn't working performance sql Issue with SQL labels Sep 4, 2024
@timsehn
Copy link
Contributor Author

timsehn commented Sep 4, 2024

This one was caused by a blocking job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working performance sql Issue with SQL
Projects
None yet
Development

No branches or pull requests

1 participant