[wp-trac] Re: [WordPress Trac] #5183: General Meta-Data Table

[WordPress Trac]

#5183: General Meta-Data Table
-----------------------------------------+----------------------------------
 Reporter:  filosofo                     |        Owner:  anonymous     
     Type:  enhancement                  |       Status:  reopened      
 Priority:  normal                       |    Milestone:  Future Release
Component:  General                      |      Version:  2.9           
 Severity:  normal                       |   Resolution:                
 Keywords:  needs-patch meta-table meta  |  
-----------------------------------------+----------------------------------

Comment(by mikeschinkel):

 Replying to [comment:36 Denis-de-Bernardy]:
 > Haven't tried MU in a while, but here's the current schema:
 >
 > http://trac.mu.wordpress.org/browser/trunk/wp-admin/includes/schema.php

 All I saw additional was sitemeta which is basically wp_options for a
 single site. Nothing to address comment meta, link meta or "whatever"
 meta.

 > Re your prior question... To me, a "real" database means when the query
 engine decides that using an index can be faster than a seq scan. (Truth
 is, most databases are so small that the query optimizer will seq scan the
 bloody mess, since the table stats show it's faster to load all pages into
 the memory anyway.) Large is when having the correct indexes becomes
 meaningful (usually 50-100k rows). Very large means you're dead unless
 your indexes are optimized to fit your queries and data. That can be 100k
 to hundreds of millions of rows, depending on the app.

 With the exception of use of the term "real" :-)  I agree.

 > As for the query you highlighted, it looks very yucky, but I'm guessing
 that the showcase.nid=%d will prompt the optimizer to return a nested loop
 plan. Whereas the odds are the optimizer will be merge joining its way
 through temporary files on the swap if you try the same with showcase.nid
 IN (..) on a few dozens of thousands of rows.

 Didn't run it through the optimizer.  Honestly I've never seen a single
 query (that I wrote) be a bottleneck on any web app I've been involved
 with, and I've dealt with 500k record tables before.  I've instead seen
 performance concerns from calling too many queries (Drupal was horrible
 for doing that, WordPress is only marginally better), from running too
 much server code per page load (Drupal's bad again, WordPress only
 slightly better), consuming too much memory per page load (Drupal is awful
 at that, WordPress not so bad), and then client-side issues: Too many HTTP
 requests, image/swf/etc files too large, HTTP caching used poorly or not
 at all, application caching not used and poorly written Javascript and/or
 Flash hogging the client processor.

 Can you actually point to several large WordPress blogs that are currently
 having performance problems explicitly because of existing database
 design?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/5183#comment:37>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software