Peter Keller <peter.keller@bvv.bayern.de> writes:
> Ok, I created a table with only one column (box), inserted 120000
> elements, created an index and run a vacuum:
> convert=# explain select * from box_tmp where ebre &&
> box('(470758.555,354028.145),(470758.525,354028.115)'::box);
> NOTICE: QUERY PLAN:
> Seq Scan on box_tmp (cost=0.00..2500.00 rows=2400 width=32)
> convert=# set enable_seqscan = off;
> SET VARIABLE
> convert=# explain select * from box_tmp where ebre &&
> box('(470758.555,354028.145),(470758.525,354028.115)'::box);
> NOTICE: QUERY PLAN:
> Index Scan using idx on box_tmp (cost=0.00..2503.28 rows=2400 width=32)
Oy vey, only three points difference in estimated costs. What is
the actual measured runtime of each approach?
> The result of the query if I set the sequential search on is this:
> convert=# select * from box_tmp where ebre &&
> box('(470758.555,354028.145),(470758.525,354028.115)'::box);
> pqReadData() -- backend closed the channel unexpectedly.
Urk. That's not supposed to happen. There should be a core file
left in your PGDATA/base/dbname/ directory --- can you provide a
backtrace from that file using gdb?
regards, tom lane