[wp-trac] [WordPress Trac] #19866: Allow specifications of any wp_posts field(s) in WP_Query

[WordPress Trac]

#19866: Allow specifications of any wp_posts field(s) in WP_Query
-----------------------------+----------------------
 Reporter:  bigdawggi        |       Owner:
     Type:  enhancement      |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Query            |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:  has-patch close  |     Focuses:
-----------------------------+----------------------

Comment (by MikeSchinkel):

 Replying to [comment:23 boonebgorges]:
 > MikeSchinkel - What sc0ttkclark said. More specifically, I'd only be
 convinced by benchmarks that demonstrate a real-life situation where
 excluding `longtext` and `text` fields significantly decreases query
 overhead, in a way that couldn't easily be avoided by using `fields=ids`.

 Understood.  I unfortunately don't have the bandwidth at the moment to
 generate said benchmarks.

 But point of note, I myself have not been concerned about performance per
 se but instead memory usage. For example, let's assume a query loads 1000
 WP Post records with the average size of a post being 2941 characters
 ''(as from my blog)'' that is almost 3Mb of memory to load said data,
 which seems like quit a lot for one query on one page load.

 Yes, we can code it so that we use two queries ''(I already do that)'' or
 maybe 1000 posts are rarely needed (although I have had code reviews where
 they required `'posts_per_page'` to be set to `999`, ''just in case'') but
 the point being that using two queries or that much memory seems to be
 overkills when all you want are just `ID`, `post_title`, `post_name` and
 maybe `post_parent` which I would guest is by for the most common need, at
 least in my use cases.

 Just sayin...

--
Ticket URL: <https://core.trac.wordpress.org/ticket/19866#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform