| From: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
|---|---|
| To: | "Paul Ramsey" <pramsey(at)refractions(dot)net> |
| Cc: | "Pg Performance list" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Proximity query with GIST and row estimation |
| Date: | 2007-02-14 18:12:54 |
| Message-ID: | 1d4e0c10702141012i139feea5q43f8ab3956cfbf09@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Paul,
On 2/14/07, Paul Ramsey <pramsey(at)refractions(dot)net> wrote:
> You'll find that PostGIS does a pretty good job of selectivity
> estimation.
PostGIS is probably what I'm going to experiment in the future. The
only problem is that it's really big for a very basic need.
With my current method, I don't even have to create a new column: I
create directly a functional index so it's really easy to use.
Using PostGIS requires to create a new column and triggers to maintain
it and install PostGIS of course. That's why it was not my first
choice.
Thanks for your answer.
--
Guillaume
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2007-02-14 18:23:38 | Re: Benchmarking PGSQL? |
| Previous Message | Tom Lane | 2007-02-14 18:07:23 | Re: reindex vs 'analyze' (was: Re: cube operations slower than geo_distance() on production server) |