Yes and no.
The post meta table is optimised for retrieving a posts keys/meta values when you already know the post ID. It is not optimised for searching and filtering.
The taxonomy tables are optimised for grouping and filtering, searching.
If you want to find all posts that have X, or Y, X and Y should be terms in a taxonomy.
If you know the data will be retrieved when you already know the post ID, use post meta. It is fast to retrieve meta belonging to a post. It is slow to do the reverse. The slowness also depends on your servers traffic as well as how much meta you’ve stored. As your site gets bigger and more popular, the cost rises quickly.
Other things to watch out for:
- avoid
not
or exclusions, they’re extremely slow/heavy/expensive on the database, always ask the database for what you want, don’t ask it to remove/exclude/hide things. Filter or X Y Z, don’t filter out A B C, it’s expensive/slow! If necessary, add extra data that says the opposite, e.g.show_on_homepage
instead ofhide_on_homepage
etc - avoid ordering by
RAND
, it is one of the worst things you can do for query performance - don’t ask for more than 100 posts per page, you can always paginate or do multiple queries
- don’t store everything as post meta, or everything ass terms/taxonomy, the point is they are good for different things, choose which for each piece of data you need to store.
- you can even store data in both, e.g. detailed data in post meta, and an approximation in a term for easy filtering. For example, storing
$5.96
in meta, and a$5-$10
term will avoid expensive query math and provide a trivial UI for users that’s fast while still storing the exact price
- you can even store data in both, e.g. detailed data in post meta, and an approximation in a term for easy filtering. For example, storing