Thread: Partial index causing wrong results to be returned on 8.1.3
I could not duplicate this on any identical database, but thought I would report it here, just for completeness. I've tried reindexing, vacuuming, etc. Explain plans all look normal. Version is 8.1.3 \d bigtable ... "bigtable_status_partial" btree (status) WHERE status::text <> 'shipped'::text =20 =20 greg=3D> select (select count(*) from bigtable where status =3D 'shipped') + (select count(*) from bigtable where status <> 'shipped') UNION select count(*) from bigtable; ?column? ---------- 1185213 1600569 =20 greg=3D> drop index bigtable_status_partial; =20 greg=3D> select (select count(*) from bigtable where status =3D 'shipped') + (select count(*) from bigtable where status <> 'shipped') UNION select count(*) from bigtable; ?column? ---------- 1185213 (1 row) -- Greg Sabino Mullane greg@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200608290003 http://biglumber.com/x/web?pk=3D2529DF6AB8F79407E94445B4BC9B906714964AC8
Greg Sabino Mullane <greg@turnstep.com> writes: > I could not duplicate this on any identical database, but thought I > would report it here, just for completeness. I've tried reindexing, > vacuuming, etc. Explain plans all look normal. Possibly explained by this 8.1.4 fix? 2006-05-18 14:57 tgl * src/backend/optimizer/plan/: createplan.c (REL8_1_STABLE), createplan.c: When a bitmap indexscan is using a partial index, it is necessary to include the partial index predicate in the scan's "recheck condition". Otherwise, if the scan becomes lossy for lack of bitmap memory, we would fail to enforce that returned rows satisfy the predicate. Noted while studying bug #2441 from Arjen van der Meijden. If it gives right answers after you increase work_mem sufficiently, I'd bet on this one ... regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If it gives right answers after you increase work_mem sufficiently, > I'd bet on this one ... That's a good bet. Changing it from 1024 to 3500 did the trick ... only one row returned, even when using the index. Thanks very much! - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200608290100 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFE88nuvJuQZxSWSsgRAkA8AJ9xKgOcEmK4swC0Dji4WtEs4p+juwCeIHJN xyNAvlAT5c2O6pWI0C2G03I= =EvGR -----END PGP SIGNATURE-----