From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: working around JSONB's lack of stats? |
Date: | 2015-02-01 21:08:01 |
Message-ID: | 54CE95B1.8020401@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 01/30/2015 05:34 PM, Jim Nasby wrote:
> On 1/30/15 2:26 PM, Josh Berkus wrote:
>> This would probably work because there aren't a lot of data structures
>> where people would have the same key:value pair in different locations
>> in the JSON, and care about it stats-wise. Alternatetly, if the same
>> key-value pair appears multiple times in the same sample row, we could
>> cut the MC% by that multiple.
>
> Even if there were multiple occurrences, this would probably still be an
> improvement.
>
> Another idea... at one time in the past when discussing statistics on
> multiple columns, one idea was to build statistics on indexes. If we
> built that, we could also do the same thing for at least JSONB (not sure
> about JSON). Obviously doesn't help for stuff you haven't indexed, but
> presumably if you care about performance and have any significant size
> of data you've also indexed parts of the JSON, yes?
I'm not clear on what you're suggesting here. I'm discussing how the
stats for a JSONB field would be stored and accessed; I don't understand
what that has to do with indexing.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Weyer | 2015-02-01 21:19:29 | Re: Unexpected (bad) performance when querying indexed JSONB column |
Previous Message | Josh Berkus | 2015-02-01 21:06:23 | Re: Unexpected (bad) performance when querying indexed JSONB column |