| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Query performance with disabled hashjoin and mergejoin |
| Date: | 2011-03-08 21:24:25 |
| Message-ID: | 28147.1299619465@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> The reason I thought cross-column correlations might be relevant is
> that the bitmap index scan on news_visible_from is quite accurate
> (19976 estimated vs. 19932 actual) and the bitmap index scan on
> news_visible_to is tolerably accurate (151 estimated vs. 41 actual)
> but the estimate on the BitmapOr is somehow totally wrong (20127
> estimated vs. 0 actual). But on further reflection that doesn't make
> much sense. How can the BitmapOr produce fewer rows than the sum of
> its constituent inputs?
That's not an estimation bug, that's a measurement bug. We don't try to
count the actual number of rows present in the result of a BitmapOr or
BitmapAnd node. (It would be impractical in lossy cases anyway, not to
mention expensive.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2011-03-08 21:56:51 | Re: Query performance with disabled hashjoin and mergejoin |
| Previous Message | Robert Haas | 2011-03-08 20:57:46 | Re: Query performance with disabled hashjoin and mergejoin |