From 7cb718f906347d03c2e21d542f3c9b9b40c63ff7 Mon Sep 17 00:00:00 2001 From: Paul Ramsey Date: Fri, 4 Feb 2005 17:08:25 +0000 Subject: [PATCH] Fixed literal && inside the text, replaced with & git-svn-id: http://svn.osgeo.org/postgis/trunk@1366 b70326c6-7e19-0410-871a-916f4a2858ee --- doc/postgis.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/postgis.xml b/doc/postgis.xml index ee2466807..90c160e77 100644 --- a/doc/postgis.xml +++ b/doc/postgis.xml @@ -2428,12 +2428,12 @@ TOAST table used 8225 pages. -Now issue a query where you use the geometry operator && to search for a +Now issue a query where you use the geometry operator && to search for a bounding box that matches only very few of those rows. Now the query optimizer sees that the table has only 3 pages and 80 rows. He estimates that a sequential scan on such a small table is much faster than using an index. And so he decides to ignore the GIST index. Usually, this -estimation is correct. But in our case, the && operator has to fetch +estimation is correct. But in our case, the && operator has to fetch every geometry from disk to compare the bounding boxes, thus reading all TOAST pages, too. @@ -2478,12 +2478,12 @@ UPDATE mytable set bbox = Envelope(Force_2d(the_geom)); -Now change your query to use the && operator against bbox instead of +Now change your query to use the && operator against bbox instead of geom_column, like: -SELECT geom_column FROM mytable WHERE bbox && SetSrid('BOX3D(0 0,1 1)'::box3d,4326); +SELECT geom_column FROM mytable WHERE bbox && SetSrid('BOX3D(0 0,1 1)'::box3d,4326); -- 2.40.0