| From: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Teodor Sigaev" <teodor(at)sigaev(dot)ru>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Remove lossy-operator RECHECK flag? |
| Date: | 2008-04-11 18:42:42 |
| Message-ID: | 1d4e0c10804111142w12bd3860qcd140b11755dff2a@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 11, 2008 at 7:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Offhand I suspect
> only the PostGIS project would be affected.
Just wanted to point out that I personnally use the capability to
remove the RECHECK of PostGIS opclass (I define a similar opclass
without the recheck) when I enforce the SRID in the application: the
overhead of rechecking the rows returned by the index scan is really
noticeable (for nothing if your SRID is the same in all your
application and data - that's what I read some time ago, hope it's
still true).
I don't know how you think PostGIS should fix their opclass after
RECHECK removal. But I'd like to have a way to keep the ability to
remove the RECHECK on my own if it's possible so I hope it won't be
hardcoded in C code somewhere.
--
Guillaume
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-04-11 18:47:26 | Re: Remove lossy-operator RECHECK flag? |
| Previous Message | Tom Lane | 2008-04-11 18:33:40 | Commit fest status |