Re: cube operations slower than geo_distance() on production server
От | Merlin Moncure |
---|---|
Тема | Re: cube operations slower than geo_distance() on production server |
Дата | |
Msg-id | b42b73150702091731x57996613hb50af0296007436c@mail.gmail.com обсуждение исходный текст |
Ответ на | cube operations slower than geo_distance() on production server (Mark Stosberg <mark@summersault.com>) |
Ответы |
Re: cube operations slower than geo_distance() on production server
|
Список | pgsql-performance |
On 2/10/07, Mark Stosberg <mark@summersault.com> wrote: > > With the help of some of this list, I was able to successfully set up > and benchmark a cube-based replacement for geo_distance() calculations. > > On a development box, the cube-based variations benchmarked consistently > running in about 1/3 of the time of the gel_distance() equivalents. > > After setting up the same columns and indexes on a production > database, it's a different story. All the cube operations show > themselves to be about the same as, or noticeably slower than, the same > operations done with geo_distance(). > > I've stared at the EXPLAIN ANALYZE output as much I can to figure what's > gone. Could you help? > > Here's the plan on the production server, which seems too slow. Below is the plan I get in > on the development server, which is much faster. > > I tried "set enable_nestloop = off", which did change the plan, but the performance. > > The production DB has much more data in it, but I still expected comparable results relative > to using geo_distance() calculations. any objection to posting the query (any maybe tables, keys, indexes, etc)? merlin
В списке pgsql-performance по дате отправления: