Hi Tom,
I found another example, in case you're interested:
This query:
SELECT * FROM meuktracker m
JOIN pwproduktrel p ON tabel = 'm' AND tabelid = m.id
WHERE m.id = (select min(id) from meuktracker where id > 7810);
It works ok if the subquery is replaced by the actual result, but this
on
Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
I found another example, in case you're interested:
Did you apply the patch?
No, it was just another test-case I stumbled upon. And I'd rather nog
install development versions of postgresql on the machine in question.
If you
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
> I found another example, in case you're interested:
Did you apply the patch?
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignor
Hi Tom,
The "zichtbaar" as false is indeed a very rare case and appearantly
isn't occuring right now. There are indeed 46631 rows in total, and all
46631 have the "zichtbaar" as true. Which reminds me to adjust the index
anyway ;-)
It appears to be happening if the fraction of zichtbaar's is
"Arjen" <[EMAIL PROTECTED]> writes:
> So, it uses the correct index, but somehow decides to also use the other
> cat2_... index, which it doesn't need of course.
I've tweaked the heuristics in choose_bitmap_and to (hopefully) work a
bit better in scenarios like this. Thanks for the example.
"Arjen" <[EMAIL PROTECTED]> writes:
>-> BitmapAnd (cost=5.62..5.62 rows=1 width=0)
> -> Bitmap Index Scan on pwprodukten_cat2_popuindex
> (cost=0.00..2.50 rows=144 width=0)
>Index Cond: (cat2 = 51)
> -> Bitmap Index Scan on pwprodukten_cat2_zichtbaar
> (c
The following bug has been logged online:
Bug reference: 2075
Logged by: Arjen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: Gentoo linux (2.6.11 kernel)
Description:Strange choice of bitmap-index-scan
Details:
I haven't tried a minima
