Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XXKAl-0003Th-JL for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Sep 2014 01:18:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XXKAl-0001V9-2F for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Sep 2014 01:18:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XXKAj-0001Uy-B7 for pgsql-hackers@postgresql.org; Fri, 26 Sep 2014 01:18:09 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XXKAf-0004Bu-8O for pgsql-hackers@postgresql.org; Fri, 26 Sep 2014 01:18:08 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1XXKAa-0005KV-5s; Thu, 25 Sep 2014 21:18:00 -0400 Date: Thu, 25 Sep 2014 21:18:00 -0400 From: Bruce Momjian To: Alexander Korotkov Cc: Emre Hasegeli , PostgreSQL Hackers , Heikki Linnakangas Subject: Re: KNN-GiST with recheck Message-ID: <20140926011800.GA8130@momjian.us> References: <20140803134809.GA58181@hasegeli-2.local> <20140914180936.GA5084@hasegeli.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.6 (--) 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 Sun, Sep 14, 2014 at 11:34:26PM +0400, Alexander Korotkov wrote: > > Cost estimation of GiST is a big problem anyway. It doesn't care (and > > can't) about amount of recheck for regular operators. In this patch, same > > would be for knn recheck. The problem is that touching heap from access This is very important work. While our existing KNN-GiST index code works fine for scalar values and point-to-point distance ordering, it doesn't work well for 2-dimensional objects because they are only indexed by their bounding boxes (a rectangle around the object). The indexed bounding box can't produce accurate distances to other objects. As an example, see this PostGIS blog post showing how to use LIMIT in a CTE to filter results and then compute the closest object (search for "LIMIT 50"): http://shisaa.jp/postset/postgis-postgresqls-spatial-partner-part-3.html This patch fixes our code for distances from a point to indexed 2-D objects. Does this also fix the identical PostGIS problem or is there something PostGIS needs to do? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers