[orf]

“It doesn’t keep statistics” is a weird way to say “I expect full table scans to always be fast”.

Create a functional index.

[aeonsky]

I’m not sure if I can even understand what you are talking about or why you said that.

If you have pid,{name:’val’, others...}. And an index of name with a million John and one Jane. Good luck getting fast results.

[orf]

> If you have pid,{name:’val’, others...}. And an index of name with a million John and one Jane. Good luck getting fast results.

Fast results: https://dbfiddle.uk/?rdbms=postgres_10&fiddle=dd9370966b1528....

Postgres does actually keep statistics on json columns, but if you've got a functional index on the table and the query uses it then it doesn't matter if there is one "jane" and a million "johns". You're looking up a key in a btree index.

[aeonsky]

No it doesn’t. But what do I know running several clusters in production for a $100 million business? Please read up on the subject before arguing.

[orf]

> SELECT most_common_vals

> FROM pg_stats

> WHERE tablename = 'json_test'

> AND attname = 'json_column';

> {"{\"name\": \"john\"}"}

Hmm. Looks like it does though. Not that it makes a damn bit of difference because if you haven't got a functional index (i.e the stats are next to useless) then you're doing a full table scan, and in that case it sounds like you “expect full table scans to always be fast” :)

And sure, the statistics don't help with the query planner, unless you've got a computed column, but again see "I expect full table scans to always be fast" and re-consider the statement "postgres doesn't keep statistics on json columns" given the fact that it actually does, just like any other column.

Read up indeed!