| From: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Question about Bitmap Heap Scan/BitmapAnd |
| Date: | 2007-02-16 00:32:42 |
| Message-ID: | 1d4e0c10702151632o3846869rddb0a9f83adfcadd@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 2/15/07, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> wrote:
> On 2/15/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I think that the
> > answer is probably "because the index is lossy for this operator,
> > so it has to be checked even if the bitmap didn't become lossy".
> > You'd have to check the GIST opclass definition to be sure.
FYI I've taken a look at PostGIS source code and the index is lossy
for the operator &&:
OPERATOR 3 && RECHECK,
(for every operator in the opclass to be exact)
--
Guillaume
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Krishna Kumar | 2007-02-16 06:09:39 | Re: Benchmarking PGSQL? |
| Previous Message | Guillaume Smet | 2007-02-15 18:09:15 | Re: Question about Bitmap Heap Scan/BitmapAnd |