| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Melese Tesfaye <mtesfaye(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1 |
| Date: | 2012-09-27 05:13:48 |
| Message-ID: | 16399.1348722828@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Melese Tesfaye <mtesfaye(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melese Tesfaye | 2012-09-27 11:16:56 | Re: BUG #7570: WHERE .. IN bug from 9.2.0 not fixed in 9.2.1 |
| Previous Message | Pavel Stehule | 2012-09-27 04:15:22 | Re: BUG #7571: Query high memory usage |