From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
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-14 16:31:22 |
Message-ID: | 200505141631.j4EGVMm16956@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Victor Y. Yegorov" <viy(at)mits(dot)lv> writes:
> > If I have on-disk bitmap
> > ON (a, b, c)
> > will the planner pick an index scan for
> > WHERE a = 42 AND b = 'foo'
> > (i.e. only part of the index attributes are involved)? Any modifications
> > needed to achieve this functionality?
>
> Hmm. That particular case will work, but 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 and gist indexes,
> so I suppose we'd need to introduce a pg_am column that tells what to
> do.
We do have a TODO for this:
* Use index to restrict rows returned by multi-key index when used with
non-consecutive keys to reduce heap accesses
For an index on col1,col2,col3, and a WHERE clause of col1 = 5 and
col3 = 9, spin though the index checking for col1 and col3 matches,
rather than just col1; also called skip-scanning.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-14 17:59:54 | Re: [HACKERS] plperl and pltcl installcheck targets |
Previous Message | Tom Lane | 2005-05-14 15:47:30 | Re: Server instrumentation for 8.1 |