Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1amYC7-0004oz-D1 for pgsql-performance@arkaria.postgresql.org; Sun, 03 Apr 2016 02:55:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1amYC5-0005Qm-W1 for pgsql-performance@arkaria.postgresql.org; Sun, 03 Apr 2016 02:55:18 +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 1amYAP-0003Vh-WF for pgsql-performance@postgresql.org; Sun, 03 Apr 2016 02:53:34 +0000 Received: from mail-lf0-x22a.google.com ([2a00:1450:4010:c07::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1amYAM-0004A9-O4 for pgsql-performance@postgresql.org; Sun, 03 Apr 2016 02:53:32 +0000 Received: by mail-lf0-x22a.google.com with SMTP id p188so95327744lfd.0 for ; Sat, 02 Apr 2016 19:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=abHbyEP9++yVywXtSF3xHAyGZ3CsfpJy85bIJ3ylZ0s=; b=pPcLqS6Mxlk3Zr0kEDDAKxb/8I0xpCcFpHg1qvrMnxAnW3TnHIlWpASGHzUUw43xWu uTN+7VLUxnjCVzFPy3eXqyYvPpmA3E0BNOHXpCGr1nF+Re7K00lUZcq5MbdsNM6fDCJq Og9b1gYWcU84HJS8DzDsiHTHNBnBaTA7/Qa6BYUCc9RTeSFHw5VJ0qXmpIg7jSDCaKjc DoV+gUYkjcBMv8/OwX8iTHqLkrrAkDXLTHnnGE4WIETENrqxpUha4tKsvnd9jvHv9uyH CYz6x+TibHggt0fEkHRP0ZK+SyunUBrHPKheYBT/A9pKA5FVzpt9ZkzPK+yGiCH3+CxK 05/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=abHbyEP9++yVywXtSF3xHAyGZ3CsfpJy85bIJ3ylZ0s=; b=jwRr9kuXDGg7x01ow7xOOUWJO4dSsFrG2i/nQDEJ/HzRHGYa8Cbb3YRt1yuo8ZLq16 Aik0aR0yZiLFKjYWoyCKEwjFrhkv0WBM5BpHIjDXPu0m3hg4HP+tXaX6sho8MwtdWa71 j3QKyRMPDeho4UAjzVW42InWxfiYytJ1mHfwknaXKCoV4f4+p9agbm2LaVgYNiIVkt+D 5CjtUK5DPsnnukSjfs66rpnitVAOuxiJ0/FaO9yeEqQH44EPNANZWovxJtQ7e0z4qzOP Km404gBNw8lLm3UHafy4LE+zeXM+cKAN4qtqs9SvQwvQxJzQ0q6Oed1ha7gYSWiLi/WS oRwA== X-Gm-Message-State: AD7BkJK57tIz2+nDl/wZCGzhX2c+8MompJsHOYbQsx3g2IiNeiS/MCW8WL9AONjc9heRw3dmL1HSmd8Y86IJ+Q== MIME-Version: 1.0 X-Received: by 10.25.166.140 with SMTP id p134mr4064308lfe.29.1459652007216; Sat, 02 Apr 2016 19:53:27 -0700 (PDT) Received: by 10.25.145.5 with HTTP; Sat, 2 Apr 2016 19:53:27 -0700 (PDT) In-Reply-To: References: <27201.1458135447@sss.pgh.pa.us> Date: Sat, 2 Apr 2016 19:53:27 -0700 Message-ID: Subject: Re: Searching GIN-index (FTS) and sort by timestamp-column From: Jeff Janes To: Oleg Bartunov Cc: Andreas Joseph Krogh , "pgsql-performance@postgresql.org" Content-Type: text/plain; charset=UTF-8 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 Tue, Mar 22, 2016 at 9:41 AM, Oleg Bartunov wrote: > > > On Sat, Mar 19, 2016 at 5:44 AM, Jeff Janes wrote: >> >> >> I don't see why it would not be possible to create a new execution node >> type that does an index scan to obtain order (or just to satisfy an equality >> or range expression), and takes a bitmap (as produced by the FTS/GIN) to >> apply as a filter. But, I don't know of anyone planning on doing that. > > > Please, find bitmap filtering patch, which we developed several months ago, > but failed to find good use case :( Teodor is here now, so he could answer > the questions. I can't find any benefit because I can't get the new node to ever execute. I set up this: create table foo as select md5(random()::text), random() as y from generate_series(1,10000000); create index on foo using gin (md5 gin_trgm_ops); create index on foo (y); vacuum ANALYZE foo ; Then when I run this: explain (analyze,buffers) select y from foo where md5 like '%abcde%' order by y limit 1 The function "cost_filtered_index(newpath)" never fires. So the planner is never even considering this feature. It seems to be getting short-circuited here: if (ipath->indexorderbys == NIL && ipath->indexorderbycols == NIL) continue; I don't know enough about the planner to know where to start on this. Cheers, Jeff -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance