Re: Problems with genetic optimizer

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