Re: cube operations slower than geo_distance() on production server

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Mark Stosberg" <mark(at)summersault(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: cube operations slower than geo_distance() on production server
Date: 2007-02-10 01:31:34
Message-ID: b42b73150702091731x57996613hb50af0296007436c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 2/10/07, Mark Stosberg <mark(at)summersault(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Stosberg 2007-02-12 16:11:19 Re: cube operations slower than geo_distance() on production server
Previous Message Virag Saksena 2007-02-10 01:08:47 Re: Is there an equivalent for Oracle's user_tables.num_rows