Re: BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1
Date
Msg-id 16399.1348722828@sss.pgh.pa.us
Whole thread Raw
In response to BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1  (mtesfaye@gmail.com)
Responses Re: BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1  (Melese Tesfaye <mtesfaye@gmail.com>)
Re: BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Melese Tesfaye <mtesfaye@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

pgsql-bugs by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: BUG #7571: Query high memory usage
Next
From: Melese Tesfaye
Date:
Subject: Re: BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1