Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UpE5T-00055L-Dd for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jun 2013 08:49:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1UpE5S-0001mj-U1 for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jun 2013 08:49:54 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UpE5R-0001mS-P1 for pgsql-hackers@postgresql.org; Wed, 19 Jun 2013 08:49:53 +0000 Received: from smtp-outbound-1.vmware.com ([208.91.2.12]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UpE5O-0003Qn-5j for pgsql-hackers@postgresql.org; Wed, 19 Jun 2013 08:49:51 +0000 Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 0000B2877B; Wed, 19 Jun 2013 01:49:48 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (zcs-prod-ext-mta-1.vmware.com [10.113.62.223]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id F17FF40749; Wed, 19 Jun 2013 01:49:48 -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 3D39F12000B; Wed, 19 Jun 2013 01:55:49 -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; Wed, 19 Jun 2013 01:55:47 -0700 (PDT) Message-ID: <51C170A8.9060509@vmware.com> Date: Wed, 19 Jun 2013 11:49:44 +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: <51BF0A90.2000503@vmware.com> <51C16235.3080308@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -6.3 (------) 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 19.06.2013 11:30, Alexander Korotkov wrote: > On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas< > hlinnakangas@vmware.com> wrote: > >> On 18.06.2013 23:59, Alexander Korotkov wrote: >> >>> I would like to illustrate that on example. Imagine you have fulltext >>> query >>> "rare_term& frequent_term". Frequent term has large posting tree while >>> >>> rare term has only small posting list containing iptr1, iptr2 and iptr3. >>> At >>> first we get iptr1 from posting list of rare term, then we would like to >>> check whether we have to scan part of frequent term posting tree where >>> iptr >>> < iptr1. So we call pre_consistent([false, true]), because we know that >>> rare term is not present for iptr< iptr2. pre_consistent returns false. >>> So >>> we can start scanning frequent term posting tree from iptr1. Similarly we >>> can skip lags between iptr1 and iptr2, iptr2 and iptr3, from iptr3 to >>> maximum possible pointer. >>> >> >> Thanks, now I understand the rare-term& frequent-term problem. Couldn't >> you do that with the existing consistent function? I don't see why you need >> the new pre-consistent function for this. > > In the case of two entries I can. But in the case of n entries things > becomes more complicated. Imagine you have "term_1& term_2& ...& term_n" > query. When you get some item pointer from term_1 you can skip all the > lesser item pointers from term_2, term_3 ... term_n. But if all you have > for it is consistent function you have to call it with following check > arguments: > 1) [false, false, false, ... , false] > 2) [false, true, false, ... , false] > 3) [false, false, true, ... , false] > 4) [false, true, true, ..., false] > ...... > i.e. you have to call it 2^(n-1) times. But if you know the query specific > (i.e. in opclass) it's typically easy to calculate exactly what we need in > single pass. That's why I introduced pre_consistent. Hmm. So how does that work with the pre-consistent function? Don't you need to call that 2^(n-1)-1 times as well? - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers