Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1agD57-0007TY-HR for pgsql-performance@arkaria.postgresql.org; Wed, 16 Mar 2016 15:09:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1agD56-0000Jp-Vm for pgsql-performance@arkaria.postgresql.org; Wed, 16 Mar 2016 15:09:53 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1agD3Q-00054l-5B for pgsql-performance@postgresql.org; Wed, 16 Mar 2016 15:08:08 +0000 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1agD3J-00015k-0m for pgsql-performance@postgresql.org; Wed, 16 Mar 2016 15:08:07 +0000 Received: by mail-wm0-x229.google.com with SMTP id l68so76950658wml.1 for ; Wed, 16 Mar 2016 08:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hA9New/8Oh+SfRUB30YzUqQI0R6qfItmWx0MyOTXm3o=; b=CU1XA0Vh+5Tr+KaE8yEI3fkJZrhnh+fEd5Yz5HSjDn4Gx6+qnlLZvxWG/MatZanzyX xhWT4ee3mcMy93YkUivKN61EakFvb+oBmxxuMgJqGLKhDTjHSn235fpHEUA/I1EKFAha eTwBWbea6PMKYU3UVbhhlehyPpqcfq8SyP3/fcB0zBvMA/Q3eisXfCrooxFxjZsNla7z H4/sfWiU8+E8iSnqTXg77nj6XOb98sV73jICUO6TqHhKVUhJ692kptyfSUSc45EInMwa +lIfCdOuRUvJQXMpls4fqBuIlU/fEjG2Pnt1DtwlewzclKfmddZ7omim4HyS+L1Fefp+ Y5ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hA9New/8Oh+SfRUB30YzUqQI0R6qfItmWx0MyOTXm3o=; b=mz352bgflUBsatg/O70omqmBLe1dDPEGiQbNzAkahO6fB9TpYTS1WAJaGZJg0VBbHl EeClrWZ5EDlWixUS0UY/57TMFmxyI4kMVkW5aseqsd2P+P3IW5uha6WN7nkdZ1ouxhwR JmcoCyGGYFBYvY4y4+OiUzNpm1u3pWKCuZl35GUVY8i3KbFQEE7FpV8dbY5vknQrKybx zU5YtsNuStWTnBOKmp+U0RgtrexN1woZbFZdHQT3AlI+/NNa86UfU0mUZ7mtn7RGPnEi LJKzYaf1j604z0y9c9/Sp3qry/ijHGp7lrjaD7fak4ic5Muue+Ajm2wHwkn89JzWBGZ4 L+4A== X-Gm-Message-State: AD7BkJJjyzf3MhZiAgzWTxZ4euj9aJse/iTmlO+ZRWNdVyeMQGxTnc33BZ1HFMI+zXRaQA== X-Received: by 10.28.6.71 with SMTP id 68mr5088872wmg.41.1458140878865; Wed, 16 Mar 2016 08:07:58 -0700 (PDT) Received: from wgaybook.corp.wargaming.local (by1-office.wargaming.net. [178.172.239.249]) by smtp.gmail.com with ESMTPSA id w10sm5990241wmw.1.2016.03.16.08.07.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 08:07:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Searching GIN-index (FTS) and sort by timestamp-column From: Evgeniy Shishkin In-Reply-To: <9D98454D-D4E5-457F-8F5C-F49526BFA9FA@gmail.com> Date: Wed, 16 Mar 2016 18:07:56 +0300 Cc: Andreas Joseph Krogh , pgsql-performance Content-Transfer-Encoding: quoted-printable Message-Id: <1C0DB3A7-0933-4931-8585-AEBA88151C4E@gmail.com> References: <27201.1458135447@sss.pgh.pa.us> <9D98454D-D4E5-457F-8F5C-F49526BFA9FA@gmail.com> To: Tom Lane X-Mailer: Apple Mail (2.3112) X-Pg-Spam-Score: -2.7 (--) 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 16 Mar 2016, at 18:04, Evgeniy Shishkin wrote: >=20 >>=20 >> On 16 Mar 2016, at 17:52, Evgeniy Shishkin wrote: >>=20 >>=20 >>> On 16 Mar 2016, at 16:37, Tom Lane wrote: >>>=20 >>> Andreas Joseph Krogh writes: >>>> 1. Why isnt' folder_id part of the index-cond? >>>=20 >>> Because a GIN index is useless for sorting. >>=20 >> I don't see how gin inability to return sorted data relates to index con= dition. >> In fact i tried to reproduce the example, >> and if i change folder_id to int from bigint, then index condition with = folder_id is used >>=20 >> Index Cond: ((fts_all @@ '''hi'''::tsquery) AND (folder_id =3D 1)) >>=20 >=20 > Looks like documentation http://www.postgresql.org/docs/9.5/static/btree-= gin.html > is lying about supporting int8 type >=20 Uh, it works if i cast to bigint explicitly WHERE del.fts_all @@ to_tsquery('simple', 'hi') AND del.folder_id =3D 1::bigint; results in=20 Index Cond: ((folder_id =3D '1'::bigint) AND (fts_all @@ '''hi''':= :tsquery)) >>=20 >>>=20 >>>> 2. Is there a way to make it use the (same) index to sort by=20 >>>> received_timestamp? >>>=20 >>> No. >>>=20 >>>> 3. Using a GIN-index, is there a way to use the index at all for sorti= ng? >>>=20 >>> No. >>>=20 >>>> 4. It doesn't seem like ts_rank uses the index for sorting either. >>>=20 >>> Same reason. >>>=20 >>> regards, tom lane >>>=20 >>>=20 >>> --=20 >>> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.o= rg) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgsql-performance --=20 Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance