[wp-trac] [WordPress Trac] #23167: Cache incrementors for get_pages

[WordPress Trac]

#23167: Cache incrementors for get_pages
----------------------------------------+------------------------
 Reporter:  nprasath002                 |       Owner:  westi
     Type:  enhancement                 |      Status:  reviewing
 Priority:  normal                      |   Milestone:  3.6
Component:  Cache                       |     Version:  trunk
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |
----------------------------------------+------------------------
Changes (by westi):

 * keywords:  has-patch => has-patch needs-unit-tests
 * owner:   => westi
 * status:  new => reviewing
 * milestone:  Awaiting Review => 3.6


Comment:

 This looks great it would be great to see a little more detail from the
 testing you did on this here for other people to understand the issue and
 how this resolves it.

 Some background for everyone:

 The basic issue as I recall is that the data cached by get_pages can get
 very large for large hierarchies because of all the "post" data being
 cached for each node - we saw an example where the memcache object cache
 backend had to split the get_pages cache into 62 1 Meg chunks.

 The patch addresses this by only caching the IDs as the post objects are
 already cached.

 Some questions for nprasath002:
  * When we don't have an object cache backend are we now doing more
 queries for get_pages calls, if so how many more - i.e. is it a single
 extra query or does the query volume scale with the number of pages (From
 memory the old code fetched all the page info in one query).
  * Can you write some unit-tests for get_pages to show that the result
 returned from the function has not changed in any way from the expected
 behaviour?

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