Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M258239=pgsql-hackers-arkari@postgresql.org>)
 id 1XXCPB-0007jk-1H
 for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Sep 2014 17:00:33 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M258239=pgsql-hackers-arkari@postgresql.org>)
 id 1XXCPA-0000nV-Gy
 for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Sep 2014 17:00:32 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
 by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <emre@hasegeli.com>) id 1XXCP8-0000lP-NF
 for pgsql-hackers@postgresql.org; Thu, 25 Sep 2014 17:00:30 +0000
Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b])
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.80) (envelope-from <emre@hasegeli.com>) id 1XXCP4-0008SA-Jb
 for pgsql-hackers@postgresql.org; Thu, 25 Sep 2014 17:00:28 +0000
Received: by mail-lb0-f171.google.com with SMTP id l4so13060269lbv.30
 for <pgsql-hackers@postgresql.org>; Thu, 25 Sep 2014 10:00:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hasegeli.com;
 s=google;
 h=date:from:to:cc:subject:message-id:references:mime-version
 :content-type:content-disposition:in-reply-to:user-agent;
 bh=OuaT9zxo1KyCoqgJuXXrQpjJt0f/ZyHjroUvyIeIIJQ=;
 b=DsOBlY6cyk5GR43I0tXlTUHGs2KNElkPlDcMgMsr+sGBjfG4v1WY2pZSEtwbtnqo2a
 nXLqKs0s8IFH1DpbpyzeTGMR9SNKSsyOejdmrm0Tkb7qyDd8NapQSucGBghtVwryzljz
 G5gGgye52LBwPN7cs6WM9zEZ4+SUcmIGApR4c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-type:content-disposition:in-reply-to
 :user-agent;
 bh=OuaT9zxo1KyCoqgJuXXrQpjJt0f/ZyHjroUvyIeIIJQ=;
 b=fty89tsqZNJphzH2mPozLgZ/ox7vdtYEDmjSUx3cuEw7FuS5jZdYkRyljCRAZ9c9Fl
 NjkROo/mg1Q+ki9Nvt9+QuSCUse9aUL4cLm7Y9QwTBmDWVg1/Xz3/G5eKax6xjX37++5
 ESM242H9gyNjNaP90TyhvHgdB2I6Iob61ntVIaDiDhsa64NnOmx0gD9LLN0CzGtj0DKT
 omEj3YLPV/khcAG+A16KwwDOBkc3vlYksEIttiZZ5EaYmxKE+JXCYKphao9KKX2M40Eb
 XRIVC7FQ/GSFGW3cxv30DtM8/KspXvdiDAJeRV2WuDYEnslyvwFvo0YNLfFnqblTns13
 0v3w==
X-Gm-Message-State: 
 ALoCoQn0mHUC0/8CD7u6O/MWMxxkExxJIXUZbMCeFZ8UxCBM0pc0kOA6b/tE5PM2aOcDlUduliEc
X-Received: by 10.112.17.2 with SMTP id k2mr14127975lbd.28.1411664422701;
 Thu, 25 Sep 2014 10:00:22 -0700 (PDT)
Received: from hasegeli.com ([24.133.146.176])
 by mx.google.com with ESMTPSA id us3sm998936lbc.24.2014.09.25.10.00.21
 for <multiple recipients>
 (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
 Thu, 25 Sep 2014 10:00:21 -0700 (PDT)
Date: Thu, 25 Sep 2014 20:00:46 +0300
From: Emre Hasegeli <emre@hasegeli.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Heikki Linnakangas <hlinnakangas@vmware.com>
Subject: Re: KNN-GiST with recheck
Message-ID: <20140925170046.GA29657@hasegeli.com>
References: 
 <CAPpHfdvn5jxgh-rVMz7c2vXoYW_W7dGrJjQkVAtaCr=-ZMCADA@mail.gmail.com>
 <20140803134809.GA58181@hasegeli-2.local>
 <CAPpHfdu3JmBrsgsrtaAQJMpXyMgrW+T2P7Gmf9oP8L1V7zLvOg@mail.gmail.com>
 <20140914180936.GA5084@hasegeli.com>
 <CAPpHfdvEpZAJrMBkNrCguG4fCK5QtZjARPti7LnL5chsSuD=Sg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
 <CAPpHfdvEpZAJrMBkNrCguG4fCK5QtZjARPti7LnL5chsSuD=Sg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Pg-Spam-Score: -2.0 (--)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

> Fixed, thanks.

Here are my questions and comments about the code.

doc/src/sgml/gist.sgml:812:
>        be rechecked from heap tuple before tuple is returned.  If
>        <literal>recheck</> flag isn't set then it's true by default for
>        compatibility reasons.  The <literal>recheck</> flag can be used only

Recheck flag is set to false on gistget.c so I think it should say
"false by default".  On the other hand, it is true by default on
the consistent function.  It is written as "the safest assumption"
on the code comments.  I don't know why the safest is chosen over
the backwards compatible for the consistent function.

src/backend/access/gist/gistget.c:505:
> 			/* Recheck distance from heap tuple if needed */
> 			if (GISTSearchItemIsHeap(*item) &&
> 				searchTreeItemNeedDistanceRecheck(scan, so->curTreeItem))
> 			{
> 				searchTreeItemDistanceRecheck(scan, so->curTreeItem, item);
> 				continue;
> 			}

Why so->curTreeItem is passed to these functions?  They can use
scan->opaque->curTreeItem.

src/backend/access/gist/gistscan.c:49:
> 		/*
> 		 * When all distance values are the same, items without recheck
> 		 * can be immediately returned.  So they are placed first.
> 		 */
> 		if (recheckCmp == 0 && distance_a.recheck != distance_b.recheck)
> 			recheckCmp = distance_a.recheck ? 1 : -1;

I don't understand why items without recheck can be immediately
returned.  Do you think it will work correctly when there is
an operator class which will return recheck true and false for
the items under the same page?

src/backend/access/index/indexam.c:258:
> 	/* Prepare data structures for getting original indexed values from heap */
> 	scan->indexInfo = BuildIndexInfo(scan->indexRelation);
> 	scan->estate = CreateExecutorState();
> 	scan->slot = MakeSingleTupleTableSlot(RelationGetDescr(heapRelation));

With the changes in indexam.c, heap access become legal for all index
access methods.  I think it is better than the previous version but
I am leaving the judgement to someone experienced.  I will try to
summarize the pros and cons of sorting the rows in the GiST access
method, as far as I understand.

Pros:

* It does not require another queue.  It should be effective to sort
  the rows inside the queue the GiST access method already has.
* It does not complicate index access method infrastructure.

Cons:

* It could be done without additional heap access.
* Other access methods could make use of the sorting infrastructure
  one day.
* It could be more transparent to the users.  Sorting information
  could be shown on the explain output.
* A more suitable data structure like binary heap could be used
  for the queue to sort the rows.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers