-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[stable22] add a prefix index to filecache.path, attempt 2 #29324
Conversation
are conflicts resolved? |
Apparently not |
7d637f2
to
a17bebd
Compare
resolved |
* @throws Exception | ||
* @since 23.0.0 | ||
*/ | ||
public function getDatabasePlatform(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
introducing a new API in a backport ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the @since
to be correct for the backport but I don't know a clean way around it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we have done backported public api's in the past like this.
I don't see a way around adding this and no real downside
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PVince81
Any objections?
moved to 22.2.2 |
The reason that `filecache.path` hasn't had an index added is the mysql limitation of ~1kb for indexeded fields, which is to small for the `path`, however mysql supports indexing only the first N bytes of a column instead of the entire column, allowing us to add an index even if the column is to long. Because the index doesn't cover the entire column it can't be used in all situations where a normal index would be used, but it does cover the `path like 'folder/path/%'` queries that are used in various places. Sqlite and Postgresql don't support prefix indexes, but they also don't have the 1kb limit and DBAL handles the differences in index creation. Signed-off-by: Robin Appelman <robin@icewind.nl>
having the index work properly for the queries we need it for requires some additional options which dbal does not support at the momement. to prevent making it harder to add the correct index later on we don't create the index for now on postgresql Signed-off-by: Robin Appelman <robin@icewind.nl>
Signed-off-by: Robin Appelman <robin@icewind.nl>
493912a
to
0aa5229
Compare
backport of #28541