Willing to accept code that adds in indexes for cck fields that get used in views filters and relationships? [#755132]

Example code here:
http://groups.drupal.org/node/57213#comment-167908

If not, I'll create a module; not a big deal. Just that a lot of people recommended this code go in your module. Odds are this code will change over time, so I would like CVS if you do plan on incorporating this code.

Let me know
-Mike

Comments

Comment #1

deekayen CreditAttribution: deekayen commented 28 March 2010 at 04:15

Version:

6.x-2.0-beta2

» 6.x-1.2

I'm not sure this is a fit, though I won't, won't fix it without a bit of discussion first.

Dalin seems unconvinced about this methodology and Moshe never really weighed in with an opinion, other than plugging other work that's been done. Can you point to something from other people (greggles, moshe, karens, david strauss, yched, markus_petrux...) that endorse this? What does it end up doing to the schema definitions - would the schema module have a fit?

Comment #2

mikeytown2 CreditAttribution: mikeytown2 commented 28 March 2010 at 18:02

Dalin had objections to adding an index to every CCK field. I now only add indexes to fields that are used in a view filter or view relationship; granted the code is about 5x bigger now, but it's a more targeted approach. Adding indexes to CCK fields that are used in a view is a standard way of optimizing MySQL for better performance. I would also add in indexes to the node_counter table as I've seen quires for that take over 300 seconds if there is not an index; with an index 20 seconds (stats on millions of nodes). The rest of these optimizations are unproven (ones at the top of the post) and thus they wouldn't be added in until they are proven. Once they are 'vetted' I would like to get them in.

The schema module seems like it's geared towards module development and not database performance, doesn't seem like the right fit. I don't know if/when the "other people" will endorse something like this.