3 ms·

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 mil

• orf 6y ago
  > 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=dd9370966b1528a2486e59c3c73ed502 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 6y ago
    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.
    • deleted 6y ago
      [deleted]
    • orf 6y ago
      > 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!