Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YHI9Z-0002Oh-8p for pgsql-performance@arkaria.postgresql.org; Fri, 30 Jan 2015 20:26:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YHI9Y-0006Ae-IS for pgsql-performance@arkaria.postgresql.org; Fri, 30 Jan 2015 20:26:56 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YHI9X-0006AX-AK for pgsql-performance@postgresql.org; Fri, 30 Jan 2015 20:26:55 +0000 Received: from mx-out.zmailcloud.com ([192.198.85.98] helo=mx-out-1.zmailcloud.com) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YHI9P-0004KE-4a for pgsql-performance@postgresql.org; Fri, 30 Jan 2015 20:26:53 +0000 Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id B2A8D5641F0; Fri, 30 Jan 2015 14:26:46 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9F896601B9; Fri, 30 Jan 2015 14:26:46 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXt7ktYgipuQ; Fri, 30 Jan 2015 14:26:46 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 75F6B60266; Fri, 30 Jan 2015 14:26:46 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5715460265; Fri, 30 Jan 2015 14:26:46 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PzYiHDXxkwOv; Fri, 30 Jan 2015 14:26:46 -0600 (CST) Received: from [172.47.23.103] (50-0-89-53.dsl.dynamic.fusionbroadband.com [50.0.89.53]) by smtp-out-2.01.com (Postfix) with ESMTPSA id D10DB601B9; Fri, 30 Jan 2015 14:26:45 -0600 (CST) Message-ID: <54CBE902.6000309@agliodbs.com> Date: Fri, 30 Jan 2015 12:26:42 -0800 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Geoghegan CC: "pgsql-performance@postgresql.org" Subject: Re: working around JSONB's lack of stats? References: <54C738E1.8080405@agliodbs.com> <54C93CF2.3020600@2ndquadrant.com> <54C96AAA.9050901@agliodbs.com> <54C973D3.6000808@agliodbs.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 01/28/2015 03:50 PM, Peter Geoghegan wrote: > On Wed, Jan 28, 2015 at 3:42 PM, Josh Berkus wrote: >> jsonb_col @> '[ "key1" ]' >> or jsonb_col ? 'key1' >> if in MCE, assign % from MCE >> otherwise assign 1% of non-MCE % >> >> jsonb_col @> '{ "key1": "value1" }' >> if in MCE, assign MCE% * 0.1 >> otherwise assign 0.01 of non-MCE % >> >> Does that make sense? > > I suspect it makes a lot less sense. The way people seem to want to > use jsonb is as a document store with a bit of flexibility. Individual > JSON documents tend to be fairly homogeneous in structure within a > table, just like with systems like MongoDB. Strings within arrays are > keys for our purposes, and these are often used for tags and so on. > But Strings that are the key of an object/pair are much less useful to > index, in my estimation. Yeah, I see your point; except for arrays, people are usually searching for a key:value pair, and the existence of the key is not in doubt. That would make the "element" the key:value pair, no? But realistically, we would only want to do that for simple keys and values. Although: if you "flatten" a nested JSON structure into just keys with scalar values (and array items as their own thing), then you could have a series of expanded key:value pairs to put into MCE. For example: { house : { city : San Francisco, sqft: 1200, color: blue, occupants: [ mom, dad, child1 ] } occupation: programmer } ... would get flattened out into the following pairs: city: san francisco sqft: 1200 color: blue occupants: [ mom ] occupants: [ dad ] occupants: [ child1 ] occupation: programmer 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. No? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance