Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Not LIVE FROM THE MINNESOTA SEARCH SPRINT, but found on the plane ride home...
The {search_dataset} has a unique key named "sid_type". Because of the query in search_wipe, which is called on every single sid that gets indexed, this unique key should be an index.
db_query("DELETE FROM {search_dataset} WHERE sid = %d AND type = '%s'", $sid, $type);
I think that this was an index at one time. And I think that this might of gotten mixed up in the conversion to schema api.
This patch should be backported to 6.x.
Comment | File | Size | Author |
---|---|---|---|
#19 | 257910.patch | 2.1 KB | chx |
#17 | 257910-search-primary-keys-followup.patch | 2.27 KB | Damien Tournoud |
#15 | 257910-search-primary-keys-followup.patch | 596 bytes | Damien Tournoud |
#13 | 257910-search-primary-keys.patch | 1.95 KB | Damien Tournoud |
#10 | issue-257910-10.patch | 1.41 KB | lilou |
Comments
Comment #1
douggreen CreditAttribution: douggreen commentedAnd here's the patch...
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis sid_type should in fact be a primary key.
The change from index to unique was consciously made during the 6.x development cycle. It lead to some problems (such as collations problems solved in #218403: Duplicate entry errors in search indexer), but it's a good choice.
Comment #3
douggreen CreditAttribution: douggreen commentedI'm not too clear on the differences here. But I do know that the current "unique key" implementation is significantly impacting this DELETE which is done on every single node that is indexed. If you know a better way, please offer the patch. Thanks!
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedI know a better way: just make this key a primary key.
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commented@Damien: How is Primary key better than a Unique key in this instance?
Comment #6
douggreen CreditAttribution: douggreen commentedA unique key is just a constraint, whereas a primary key is an index. You get no performance gain from constraints, but you do from indexes.
Comment #7
Damien Tournoud CreditAttribution: Damien Tournoud commented@douggreen: In fact, for MySQL the difference is not very clear. MySQL also creates an index for UNIQUE KEY, but it's not clear to me if there is prefix and suffix compression for these indexes, nor whereas MySQL can use it to lookup values. Moreover, PRIMARY KEYS are clustered (the physical order of rows change), whereas other index types are non-clustered.
For the
{search_dataset}
particular case, aPRIMARY KEY
is what makes sense anyway.Comment #8
douggreen CreditAttribution: douggreen commentedI do know that the unique key in mysql is giving terrible performance on the
DELETE FROM {search_dataset} WHERE sid = %d AND type = '%s'
, so it surprises me to hear that "MySQL also creates an index for UNIQUE KEY."Comment #9
robertDouglass CreditAttribution: robertDouglass commentedSubscribe.
Comment #10
lilou CreditAttribution: lilou commentedReroll patch #1 and add description to update function.
Comment #11
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #12
Damien Tournoud CreditAttribution: Damien Tournoud commentedSorry, why removing the unique constraint? It makes total sense!
Comment #13
Damien Tournoud CreditAttribution: Damien Tournoud commentedHere is a revert of #10, changing the unique constraints in search_index and search_dataset by primary keys.
Comment #14
Dries CreditAttribution: Dries commentedI think you're right. Committed the follow-up patch.
Comment #15
Damien Tournoud CreditAttribution: Damien Tournoud commentedSorry, finally forgot to drop the redundant 'word' index in the schema.
Comment #16
mfbThere's an update script in system.install running on the search tables, but search module and its tables may not even be installed! This causes errors at update.php. The update script should be in search.install instead.
Comment #17
Damien Tournoud CreditAttribution: Damien Tournoud commentedOups.
Comment #18
webchickThis no longer applies because of some whitespace changes in #303889: Impossible to update D6 -> D7 but should be a quick re-roll.
Comment #19
chx CreditAttribution: chx commentedComment #20
kbahey CreditAttribution: kbahey commentedI tested this on top of #46 in http://drupal.org/node/303889, and that combination made update.php work again.
Comment #21
webchickThird time's a charm? :)
Comment #22
Damien Tournoud CreditAttribution: Damien Tournoud commentedI'm pretty sure this issue will came back to haunt us. A ghost will step in, and say "this is an *horrible* idea, please revert". The only question is: when will that happen?