Re: Problems with genetic optimizer

Peter Keller <peter(dot)keller(at)bvv(dot)bayern(dot)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