Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M259087=pgsql-hackers-arkari@postgresql.org>)
 id 1Xb4hk-0006Vk-OS
 for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Oct 2014 09:35:44 +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+M259087=pgsql-hackers-arkari@postgresql.org>)
 id 1Xb4hk-0000nn-8e
 for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Oct 2014 09:35:44 +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 1Xb4hi-0000nd-M0
 for pgsql-hackers@postgresql.org; Mon, 06 Oct 2014 09:35:43 +0000
Received: from mail-la0-x22e.google.com ([2a00:1450:4010:c03::22e])
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.80) (envelope-from <emre@hasegeli.com>) id 1Xb4ha-0005YE-Kr
 for pgsql-hackers@postgresql.org; Mon, 06 Oct 2014 09:35:40 +0000
Received: by mail-la0-f46.google.com with SMTP id gi9so3971740lab.5
 for <pgsql-hackers@postgresql.org>; Mon, 06 Oct 2014 02:35:30 -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=k4xHb1DKU77qh681nPMiaSu59veOr8ulc4mx+x4uhBg=;
 b=qykODLvrfybkx7sJUDpAPg5xh4eAUiKZ6ClP+OyQd4kklr0HYSV5kpaf/XZJa+l21m
 VdEy4N/BwP84PeOS2RyX2+D+0hZioqoAkEknsxf2p1MlSa5FSxsvUC7B/oaPJs7aBbFa
 8cI0rOUW3oEZVscxchmgKfTLlfL78rxxcwSFo=
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=k4xHb1DKU77qh681nPMiaSu59veOr8ulc4mx+x4uhBg=;
 b=UVRCnjRiLmmF+YqcJlcWnUt/uIXnRDybdwKSvi/zsB8UoPmt4zvsrjmGIYKGr9F1rc
 V57Cj3GBYpTYvwLxGnevAhwKZgK6FtwUdDjWBaITYOBruiv9RH2FuoBSM83LmoiBF+Pa
 Ipgz0sbmQ50L4onvLiiYMDteq767EHpcaMp1gyuWim6FMepMXh6PeYgm+PwElj1ezpks
 RhRIJkzU3HhZ0OYVdXpxj3mcV6qUaNioZb1MB3Pdk6EkFaEBKPDWp+oqKma8QXBIiH8p
 M+cK4L1P3tezVx8OQzUdaa+zRKTz9Z0u/Q7fSA0nyHcHxvx1IuQbxG4SxdCnynB+yVK4
 yr9Q==
X-Gm-Message-State: 
 ALoCoQmL2q9inWw7E4iMM8EFWFkllNDDxr3k7bdqf/8zgUAhpnb08p+qTdmMseOp9T5AUheYtHIo
X-Received: by 10.152.20.98 with SMTP id m2mr23596500lae.51.1412588130843;
 Mon, 06 Oct 2014 02:35:30 -0700 (PDT)
Received: from hasegeli.com ([24.133.146.176])
 by mx.google.com with ESMTPSA id v6sm5538283lbb.33.2014.10.06.02.35.28
 for <multiple recipients>
 (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
 Mon, 06 Oct 2014 02:35:29 -0700 (PDT)
Date: Mon, 6 Oct 2014 12:36:09 +0300
From: Emre Hasegeli <emre@hasegeli.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>,
 Heikki Linnakangas <hlinnakangas@vmware.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: KNN-GiST with recheck
Message-ID: <20141006093609.GA12899@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>
 <20140926011800.GA8130@momjian.us>
 <CAPpHfdvDMS1_jqnzZ0FbGePWwCvStj4_h0xU2hYTnLcC6of3Rg@mail.gmail.com>
 <20140929021631.GG12447@momjian.us>
 <CAPpHfdvdL0dtoNBmbCsJ=W0bFE7A87hLOtoBN7Pe4hnXkQ9LxA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
 <CAPpHfdvdL0dtoNBmbCsJ=W0bFE7A87hLOtoBN7Pe4hnXkQ9LxA@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

> Thanks. The main question now is design of this patch. Currently, it does
> all the work inside access method. We already have some discussion of pro
> and cons of this method. I would like to clarify alternatives now. I can
> see following way:
> 
>    1. Implement new executor node which performs sorting by priority queue.
>    Let's call it "Priority queue". I think it should be separate node from
>    "Sort" node. Despite "Priority queue" and "Sort" are essentially similar
>    from user view, they would be completely different in implementation.
>    2. Implement some interface to transfer distance values from access
>    method to "Priority queue" node.

If we assume that all of them need recheck, maybe it can be done
without passing distance values.

>    3. Somehow tell the planner that it could use "Priority queue" in
>    corresponding cases. I see two ways of doing this:
>       - Add flag to operator in opclass indicating that index can only
>       order by lower bound of "col op value", not by "col op value" itself.
>       - Define new relation between operators. Value of one operator could
>       be lower bound for value of another operator. So, planner can
> put "Priority
>       queue" node when lower bound ordering is possible from index. Also "ALTER
>       OPERATOR" command would be reasonable, so extensions could upgrade.

I think, it would be better to make it a property of the operator
class.  We can add a column to pg_amop or define another value for
amoppurpose on pg_amop.  Syntax can be something like this:

CREATE OPERATOR CLASS circle_ops DEFAULT
   FOR TYPE circle USING gist AS
   OPERATOR 15  <->(circle, point) FOR ORDER BY pg_catalog.float_ops LOWER BOUND;

While looking at it, I realize that current version of the patch does
not use the sort operator family defined with the operator class.  It
assumes that the distance function will return values compatible with
the operator.  Operator class definition makes me think that there is
not such an assumption.

> Besides overhead, this way makes significant infrastructural changes. So,
> it may be over-engineering. However, it's probably more clean and beautiful
> solution.
> I would like to get some feedback from people familiar with KNN-GiST like
> Heikki or Tom. What do you think about this? Any other ideas?

I would be happy to test and review the changes.  I think it is nice
to solve the problem in a generalized way improving the access method
infrastructure.  Definitely, we should have a consensus on the design
before working on the infrastructure changes.


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