[Wikidata-bugs] [Maniphest] [Commented On] T99459: ips_site_page is to short to store some (fulll) page titles

2015-05-17 Thread Springle
Springle added a comment. Smaller fields are still better for performance, so I vote for a conservative 300, unless 400 is demonstrably needed. Correct, 767 bytes (bytes, not characters) is the limit for a single InnoDB index with our current DB config, which is enough, and in any case with a

[Wikidata-bugs] [Maniphest] [Commented On] T99459: ips_site_page is to short to store some (fulll) page titles

2015-05-17 Thread hoo
hoo added a comment. This shouldn't be an issue, I think indexes can be up to 767bytes without any issues. For completeness, I've tested this: Production: EXPLAIN SELECT * FROM wb_items_per_site WHERE ips_site_id = 'dewiki' AND ips_site_page = 'Berlin'\G *** 1. row

[Wikidata-bugs] [Maniphest] [Commented On] T99459: ips_site_page is to short to store some (fulll) page titles

2015-05-17 Thread daniel
daniel added a comment. Ok then, thanks for checking! TASK DETAIL https://phabricator.wikimedia.org/T99459 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Krenair, jcrespo, Springle, Lydia_Pintscher, aude, daniel, Aklapper, hoo,

[Wikidata-bugs] [Maniphest] [Commented On] T99459: ips_site_page is to short to store some (fulll) page titles

2015-05-17 Thread daniel
daniel added a comment. I feat that MySQL doesn't fully index varchar fields wider than 255 characters (or even bytes?). And I'm unsure if it's smart enough to fall back to prefix search and post-processing. I seem to recall that this doesn't work. Can you compare the output of EXPLAIN for the