Message-ID: <54C93CF2.3020600@2ndquadrant.com>
Date: Wed, 28 Jan 2015 20:48:02 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Organization: 2ndQuadrant
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: working around JSONB's lack of stats?
References: <54C738E1.8080405@agliodbs.com>
In-Reply-To: <54C738E1.8080405@agliodbs.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 27.1.2015 08:06, Josh Berkus wrote:
> Folks,
> 
...
>
> On a normal column, I'd raise n_distinct to reflect the higher
> selecivity of the search terms.  However, since @> uses contsel,
> n_distinct is ignored.  Anyone know a clever workaround I don't
> currently see?

I don't see any reasonable workaround :-(

ISTM we'll have to invent a way to collect useful stats about contents
of JSON/JSONB documents. JSONB is cool, but at the moment we're mostly
relying on defaults that may be reasonable, but still misfire in many
cases. Do we have any ideas of how that might work?

We're already collecting stats about contents of arrays, and maybe we
could do something similar for JSONB? The nested nature of JSON makes
that rather incompatible with the flat MCV/histogram stats, though.

regards
-- 
Tomas Vondra                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance