@Howdy_McGee It actually is a marketing method that I've seen being used by some major companies. The least is to let the viewer know they can check back later, if they need the future features.

Also, I'm very confused about the reason that WP_Query takes so long when u feed it a meta query. It's super fast to query wp_posts based on fields, also fast to query wp_postmeta based on key/value fields, and even faster to run array_diff on the results to get the final result.

@JackJohansson because meta_query is slow

the post meta table is optimised for finding keys/values when you already know the post ID

taxonomies/terms are the reverse

so if you ask the database for all post IDs that have a key/value in the post meta table, it's expensive, and gets more expensive as the table grows in size

whereas if you use get_post_meta it can rely on indexes to make the query super fast

additionally, if you retrieve a post, WP fetches the post meta all at once to prime the cache so get_post_meta doesn't involve a DB query

granted that cache dissapears at the end of the request unless you have an object cache

But if I use something like "SELECT post_id FROM wp_postmeta WHERE meta_key = 123 AND meta_value = 456" it's still fast.

most likely because 456 is short and numeric

that doesn't mean it's advisable

an index was added for keys IIRC that catered to short integer IDs

it's also possible you just don't have much data

post meta query time does not scale linearly

100x as much data is worse, 1000x as much data is more so

unlike 100x as many posts vs 1000x as many posts

those are example inputs

post meta is not optimised for searching and filtering posts and was never intended to be

that's what taxonomies and terms are for

otherwise terms would just be post meta

My question is more technical than practical. We use the same method to query posts, and it's fast

you should not

How could it be fast to query using post-slug but not fast using meta_key

post slugs are not stored in post meta

they're stored on the post table itself in an indexed column

and as I said, the post meta table is not optimised for searching for posts

it's optimised for finding a key/value when you already know the post ID

codex.wordpress.org/Database_Description#Indexes_5

the post meta table index is post ID <-> meta key

so any query that tries to use the values instead is going to be slow

on a site that's small you won't notice this

These 2 for example

let's forget about everything else

you're using examples that have no context

also you specified the key

Yes i did, in all my examples

that same query will have different performance on a site with 4 posts, vs a site with 400 vs a site with 40k posts

no you did not

you have given zero information about the quantity of posts

zero timings too

...

querying the post meta table for post IDs is not what the table was optimised for. That is why it's slow

specifically because values are not indexed

a database might be able to optimise things by using the index to filter it down on a key

for that you would need to run an EXPLAIN to see the exact query plan

Now we're getting close

but you shouldn't be storing data you intend to search and filter posts by in post meta

The above is nothing I haven't already said earlier

post meta queries do not scale as the size of a site grows

from my time at VIP they're notoriously bad for bringing down database instances are causing performance problems

so when it says IND on the codex, it means that database is able to search for that column faster?

like post_data, post_status etc?

that's what indexes are, if the database has to scan each row of a table that's a slow thing to do, and something to avoid, indexes are structures designed to speed up queries by providing shortcuts

Now we're talking

they're structured internally different from tables

Didn't know about internal indexing, haven't worked with DB much

So when it says meta_key is indexed, it makes it faster if I specify it?

finding meta keys is faster

that's why a query for get_post_meta is fast, because it doesn't scan the table, it uses the index

So basically yes

not really, the statement is too simple

it depends on the query

and the query plan

you can quite easily ruin the performance dramatically by throwing in a a clause saying you don't want rows that have a value smaller than 5

at that point the database might build a brand new table in memory as a preparation step for running the query

likewise if you sort randomly, it'll create a copy of the table, but with the order shuffled

I know, i'm talking about the fundamentals, nothing else is involved here. It's laboratory environment

We're finding the rat here :)