I wrote:
> Argh. The problem query has a plan like this: ...
> 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,
I've committed a patch for this. Thanks for the report!
Thanks Tom,
I do have a self-contained test case which duplicates the problem. However,
since there are data to be attached and there wasn't a way to attach in the
bug reporting form, I wasn't sure how to proceed.
Would appreciate your assistance.
Thanks again.
On Wed, Sep 26, 2012 at 11:13 PM, T
Thanks Tom,
Yes, that did it - it worked after setting enable_mergejoin to off.
mtesfaye@[local](test_db)=# set enable_mergejoin = off;
SET
Time: 0.107 ms
mtesfaye@[local](test_db)=# SELECT DISTINCT(A.*)
FROM table1_t A LEFT JOIN table2_v B
ON A.pnr_id=B.pnr_id
WHERE A.pnr_id IN(1801,2056) AND
Melese Tesfaye 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
(co
Melese Tesfaye writes:
> I do have a self-contained test case which duplicates the problem. However,
> since there are data to be attached and there wasn't a way to attach in the
> bug reporting form, I wasn't sure how to proceed.
Just send it to the pgsql-bugs@postgresql.org mailing list. (If y
mtesf...@gmail.com writes:
> I had a problem with missing rows in a resultset when using WHERE .. IN
> after upgrading to 9.2.0.
We'll need a self-contained test case to investigate that. The query
alone is of no help without table definitions and sample data sufficient
to reproduce the misbehavi
The following bug has been logged on the website:
Bug reference: 7570
Logged by: Melese Tesfaye
Email address: mtesf...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Ubuntu 12.04.1 LTS + Debian 6 (both x86_64
Description:
I had a problem with missing rows in a
