Skip site navigation (1) Skip section navigation (2)

Re: Help with query plan inconsistencies

From: Richard Huxton <dev(at)archonet(dot)com>
To: Woody Woodring <george(dot)woodring(at)iglass(dot)net>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Help with query plan inconsistencies
Date: 2004-03-24 16:44:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Tuesday 23 March 2004 18:49, Woody Woodring wrote:
> Hello,
> I am using postgres 7.4.2 as a backend for geocode data for a mapping
> application.  My question is why can't I get a consistent use of my indexes
> during a query, I tend to get a lot of seq scan results.

I'm not sure it wants to be using the indexes all of the time.

>  Nested Loop Left Join  (cost=0.00..23433.18 rows=1871 width=34) (actual
> time=0.555..5095.434 rows=3224 loops=1)
>  Total runtime: 5100.028 ms

>  Nested Loop Left Join  (cost=0.00..76468.90 rows=9223 width=34) (actual
> time=0.559..17387.427 rows=19997 loops=1)
>  Total runtime: 17416.501 ms

>  Nested Loop Left Join  (cost=0.00..29160.02 rows=2327 width=34) (actual
> time=0.279..510.773 rows=5935 loops=1)
>  Total runtime: 516.782 ms

#1 = 630 rows/sec (with index on cable_billing)
#2 = 1,148 rows/sec (without index)
#3 = 11,501 rows/sec (with index)

The third case is so much faster, I suspect the data wasn't cached at the 
beginning of this run.

In any case #2 is faster than #1. If the planner is getting things wrong, 
you're not showing it here.

  Richard Huxton
  Archonet Ltd

In response to

pgsql-performance by date

Next:From: pginfoDate: 2004-03-24 16:49:55
Subject: Re: slow vacuum performance
Previous:From: Rosser SchwarzDate: 2004-03-24 16:38:35
Subject: Re: atrocious update performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group