| From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Victor Y(dot) Yegorov" <viy(at)mits(dot)lv>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Best way to scan on-disk bitmaps |
| Date: | 2005-05-15 19:22:59 |
| Message-ID: | ja8f815ef3o3o6eab4gu6fo223p43iqq1a@4ax.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 12 May 2005 17:40:06 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>the planner believes that only
>consecutive columns in the index are usable --- that is, if you have
>quals for a and c but not for b, it will think that the condition for c
>isn't usable with the index. This is true for btree [...]
It's not difficult to setup a test case where an index is used, but
only with a=42 as an index condition, and c='foo' is applied as a
filter condition. Now add a redundant condition on b
... AND b BETWEEN minb AND maxb ...
and watch how c='foo' moves into the index condition.
I did this test some time ago and I believe that adding the condition
on b did not change the estimated cost, only the actual execution
time.
Servus
Manfred
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-05-15 19:27:51 | Re: Best way to scan on-disk bitmaps |
| Previous Message | Manfred Koizar | 2005-05-15 19:21:53 | Re: Views, views, views! (long) |