Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UoZBz-0003Ak-89 for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Jun 2013 13:09:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1UoZBy-00074T-NZ for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Jun 2013 13:09:54 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UoZBx-00074L-JP for pgsql-hackers@postgresql.org; Mon, 17 Jun 2013 13:09:53 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UoZBl-0005Oc-PT for pgsql-hackers@postgresql.org; Mon, 17 Jun 2013 13:09:51 +0000 Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 2E2F328102; Mon, 17 Jun 2013 06:09:39 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (zcs-prod-ext-mta-1.vmware.com [10.113.62.223]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 2AE2DB09DF; Mon, 17 Jun 2013 06:09:39 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTP id 023AE12000B; Mon, 17 Jun 2013 06:15:37 -0700 (PDT) Received: from [192.168.1.90] (zimbra-prod-ext-proxy-vip.vmware.com [10.113.63.87]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTPSA; Mon, 17 Jun 2013 06:15:36 -0700 (PDT) Message-ID: <51BF0A90.2000503@vmware.com> Date: Mon, 17 Jun 2013 16:09:36 +0300 From: Heikki Linnakangas Organization: VMware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Alexander Korotkov CC: pgsql-hackers Subject: Re: GIN improvements part2: fast scan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -8.0 (--------) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 17.06.2013 15:55, Alexander Korotkov wrote: > On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkovwrote: > >> attached patch implementing "fast scan" technique for GIN. This is second >> patch of GIN improvements, see the 1st one here: >> >> http://www.postgresql.org/message-id/CAPpHfduxv-iL7aedwPW0W5fXrWGAKfxijWM63_hZujaCRxnmFQ@mail.gmail.com >> This patch allow to skip parts of posting trees when their scan is not >> necessary. In particular, it solves "frequent_term& rare_term" problem of >> FTS. >> It introduces new interface method pre_consistent which behaves like >> consistent, but: >> 1) allows false positives on input (check[]) >> 2) allowed to return false positives >> >> Some example: "frequent_term& rare_term" becomes pretty fast. >> >> create table test as (select to_tsvector('english', 'bbb') as v from >> generate_series(1,1000000)); >> insert into test (select to_tsvector('english', 'ddd') from >> generate_series(1,10)); >> create index test_idx on test using gin (v); >> >> postgres=# explain analyze select * from test where v @@ >> to_tsquery('english', 'bbb& ddd'); >> QUERY PLAN >> >> ----------------------------------------------------------------------------------------------------------------------- >> Bitmap Heap Scan on test (cost=942.75..7280.63 rows=5000 width=17) >> (actual time=0.458..0.461 rows=10 loops=1) >> Recheck Cond: (v @@ '''bbb''& ''ddd'''::tsquery) >> -> Bitmap Index Scan on test_idx (cost=0.00..941.50 rows=5000 >> width=0) (actual time=0.449..0.449 rows=10 loops=1) >> Index Cond: (v @@ '''bbb''& ''ddd'''::tsquery) >> Total runtime: 0.516 ms >> (5 rows) >> > > Attached version of patch has some refactoring and bug fixes. Good timing, I just started looking at this. I think you'll need to explain how this works. There are no docs, and almost no comments. (and this shows how poorly I understand this, but) Why does this require the "additional information" patch? What extra information do you store on-disk, in the additional information? The pre-consistent method is like the consistent method, but it allows false positives. I think that's because during the scan, before having scanned for all the keys, the gin AM doesn't yet know if the tuple contains all of the keys. So it passes the keys it doesn't yet know about as 'true' to pre-consistent. Could that be generalized, to pass a tri-state instead of a boolean for each key to the pre-consistent method? For each key, you would pass "true", "false", or "don't know". I think you could then also speed up queries like "!english & bbb". - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers