database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Finish repairing 6.5's problems with r-tree indexes: create appropriate

Browse Source 
selectivity functions and make the r-tree operators use them.  The
estimation functions themselves are just stubs, unfortunately, but
perhaps someday someone will make them compute realistic estimates.
Change pg_am so that the optimizer can reliably tell the difference
between ordered and unordered indexes --- before it would think that
an r-tree index can be scanned in '<<' order, which is not right AFAIK.
Repair broken negator links for network_sup and related ops.
Initdb forced.  This might be my last initdb force for 7.0 ... hope so
anyway ...
This commit is contained in:
Tom Lane
2000-02-17 03:40:02 +00:00
parent cf880a6160
commit 598ea2c359
12 changed files with 249 additions and 181 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
src/test/regress/expected/create_index.out
View File

@ -47,10 +47,22 @@ CREATE INDEX bt_f8_index ON bt_f8_heap USING btree (seqno float8_ops);
--
-- rtrees use a quadratic page-splitting algorithm that takes a
-- really, really long time. we don't test all rtree opclasses
-- in the regression test (we check them USING the sequoia 2000
-- in the regression test (we check them using the sequoia 2000
-- benchmark).
--
CREATE INDEX rect2ind ON fast_emp4000 USING rtree (home_base bigbox_ops);
-- there's no easy way to check that this command actually is using
-- the index, unfortunately. (EXPLAIN would work, but its output
-- changes too often for me to want to put an EXPLAIN in the test...)
SELECT * FROM fast_emp4000
WHERE home_base @ '(200,200),(2000,1000)'::box
ORDER BY home_base USING <<;
home_base
-----------------------
(337,455),(240,359)
(1444,403),(1346,344)
(2 rows)
--
-- HASH
--

8
src/test/regress/sql/create_index.sql
View File

@ -70,11 +70,17 @@ CREATE INDEX bt_f8_index ON bt_f8_heap USING btree (seqno float8_ops);
--
-- rtrees use a quadratic page-splitting algorithm that takes a
-- really, really long time. we don't test all rtree opclasses
-- in the regression test (we check them USING the sequoia 2000
-- in the regression test (we check them using the sequoia 2000
-- benchmark).
--
CREATE INDEX rect2ind ON fast_emp4000 USING rtree (home_base bigbox_ops);
-- there's no easy way to check that this command actually is using
-- the index, unfortunately. (EXPLAIN would work, but its output
-- changes too often for me to want to put an EXPLAIN in the test...)
SELECT * FROM fast_emp4000
WHERE home_base @ '(200,200),(2000,1000)'::box
ORDER BY home_base USING <<;
--
-- HASH