Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YI5xG-00059B-PV for pgsql-performance@arkaria.postgresql.org; Mon, 02 Feb 2015 01:37:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YI5xF-00084z-Qi for pgsql-performance@arkaria.postgresql.org; Mon, 02 Feb 2015 01:37:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YI5xE-00084s-Oo for pgsql-performance@postgresql.org; Mon, 02 Feb 2015 01:37:32 +0000 Received: from mwork.nabble.com ([162.253.133.43]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YI5xA-0002sY-6q for pgsql-performance@postgresql.org; Mon, 02 Feb 2015 01:37:31 +0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id 777B71283625 for ; Sun, 1 Feb 2015 17:37:26 -0800 (PST) Date: Sun, 1 Feb 2015 18:37:26 -0700 (MST) From: AlexK987 To: pgsql-performance@postgresql.org Message-ID: <1422841046401-5836323.post@n5.nabble.com> In-Reply-To: <6888.1422833653@sss.pgh.pa.us> References: <1422829941197-5836319.post@n5.nabble.com> <6888.1422833653@sss.pgh.pa.us> Subject: Re: Why is GIN index slowing down my query? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -0.1 (/) 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 Tom, This is a realistic case: everyone have Python and Java skills, but PostGis and Haskell and Closure are rare. If we are looking for a person that has all the skills required for a task (array[1, 15]), that is "skills <@ array[1, 15] " and not the opposite, right? Also can you explain why " entries for "0" and "1" swamp everything else so that the planner doesn't know that eg "15" is really rare. " I thought that if a value is not found in the histogram, than clearly that value is rare, correct? What am I missing here? I hear what you are saying about "don't keep both extremely common and extremely rare entries in the same array", but I cannot predict the future, so I do not know which values are going to be common next year, or two years later. So I think it would be very difficult to follow this advice. What do you think? -- View this message in context: http://postgresql.nabble.com/Why-is-GIN-index-slowing-down-my-query-tp5836319p5836323.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance