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
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 |