Melese Tesfaye <mtesf...@gmail.com> writes: > [ test case ] Argh. The problem query has a plan like this:
-> Merge Join (cost=1084.06..1354.58 rows=4 width=13) Merge Cond: (table2_t.pnr_id = a.pnr_id) -> stuff ... -> Index Scan using table1_t_pnr_id_idx5 on table1_t a (cost=0.00..12.60 rows=4 width=13) Index Cond: (pnr_id = ANY ('{1801,2056}'::integer[])) which means the indexscan has to support mark/restore calls. And it looks like I blew it on mark/restore support when I taught btree to handle =ANY conditions natively, http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=9e8da0f75731aaa7605cf4656c21ea09e84d2eb1 Will look into fixing that tomorrow. In the meantime, you should be able to work around this with "set enable_mergejoin = off". regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs