[wp-trac] Re: [WordPress Trac] #3174: SQL cacher

[WordPress Trac]

#3174: SQL cacher
--------------------------+-------------------------------------------------
 Reporter:  quix0r        |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:           
Component:  Optimization  |      Version:  2.1      
 Severity:  normal        |   Resolution:           
 Keywords:  sql,cache     |  
--------------------------+-------------------------------------------------
Comment (by masquerade):

 -1 for a few reasons.

 First and foremost, the built-in WP object cache will achieve much of the
 same purpose, with a more pluggable backend. A few queries are still left,
 but imho we need them for sanity's sake, if we don't ever use the DB
 there's no point in opening the connection, and we don't know at any point
 whether or not the DB is actually still up if we don't open the connection
 and test in some way to see if WP is installed.

 -the fact that there is compression for a cache file. To me, running a
 cache file through a compression algorithm of any sort is extra CPU cycles
 that you might as well have spent fetching the query over again.
 -You die if a cache file can't be created, and ask for specific
 permissions (0777) on the cache directoy/files. Bad bad bad. Silently fail
 and work like normal, and we should not necessarily promote the use of
 insecure permissions on directories in any way in the core.
 -Reliance on Apache to stop calls to the cache directory. Not everyone
 uses apache, believe it or not.
 -In your implementation, select * from wp_posts would not be cached.
 -PHP destroys objects and connections on shutdown, I see no purpose in
 doing it mid-request and/or needlessly doing it at the end

-- 
Ticket URL: <http://trac.wordpress.org/ticket/3174>
WordPress Trac <http://wordpress.org/>
WordPress blogging software