Peter Eisentraut <[EMAIL PROTECTED]> writes:
> OK, upgrading to 8.2.4 fixes this odd plan choice. The query does run
> a bit faster too, but the cost estimate has actually gone up!
Yeah, because the former code was making an unrealistically small
estimate of the number of tuples found by BitmapAn
Am Mittwoch, 9. Mai 2007 16:29 schrieb Alvaro Herrera:
> Peter Eisentraut wrote:
> > There's another odd thing about this plan from yesterday.
>
> Is this still 8.2.1? The logic to choose bitmap indexes was rewritten
> just before 8.2.4,
OK, upgrading to 8.2.4 fixes this odd plan choice. The que
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm wondering what it wants to achieve with these three index scans:
See if you still get that with 8.2.4. choose_bitmap_and was fairly far
out in left field before that :-( ... particularly for cases with
partially redundant indexes available.
Peter Eisentraut wrote:
> There's another odd thing about this plan from yesterday.
Is this still 8.2.1? The logic to choose bitmap indexes was rewritten
just before 8.2.4,
2007-04-17 16:03 tgl
* src/backend/optimizer/path/indxpath.c:
Rewrite choose_bitmap_and() to make it more robust in
There's another odd thing about this plan from yesterday.
Query:
SELECT
eh_subj.header_body AS subject,
count(distinct eh_from.header_body)
FROM
email JOIN mime_part USING (email_id)
JOIN email_header eh_subj USING (e
