WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #39358, comment 9


Ignore:
Timestamp:
12/22/2016 12:45:43 AM (8 years ago)
Author:
dd32
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #39358, comment 9

    initial v1  
    11> c) Limit it to exact matches only for the postmeta, which with the help of a new DB index would make it much faster.
    22
    3 To follow that up, it'd actually have to be done with the help of a new meta key.. The reason being, is that the meta values are currently stored like so: `2015/01/G6JgkNp.jpg` OR `/home/someuser/public_html/wp-content/uploads/oj0KHQm.jpg`. Exact-matching and/or indexing isn't going to help here without a rethink of where the filename is available.
     3To follow that up, it'd actually have to be done with the help of a new meta key.. The reason being, is that the meta values are currently stored like so: `2015/01/08W0zJv.jpg` OR `/home/someuser/public_html/wp-content/uploads/08W0zJv.jpg`. Exact-matching and/or indexing isn't going to help here without a rethink of where the filename is available.
    44
    5 We could use the fact that the `post_name` field is going contain the basename of the filename, ie. `g6jgknp` in the case of `G6JgkNp.jpg`, combined with the fact that the Guid field ''currently'' contains the filename. That would at least cause it to hit indexes and not require a table join, for example (note the 4th search OR in both the previous and this example)
     5We could use the fact that the `post_name` field is going contain the basename of the filename, ie. `08w0zjv` in the case of `08W0zJv.jpg`, combined with the fact that the Guid field ''currently'' contains the filename. That would at least cause it to hit indexes and not require a table join, for example (note the 4th search OR in both the previous and this example)
    66
    77{{{