* David Jarvis (thangalin(at)gmail(dot)com) wrote:
> I was still referring to the measurement table. You have an index on
> > stationid, but still seem to be getting a sequential scan. Maybe the planner
> > does not realise that you are selecting a small number of stations. Posting
> > an EXPLAIN ANALYSE would really help here.
> Here is the result from an *EXPLAIN ANALYZE*:
Yeah.. this is a horrible, horrible plan. It does look like you've got
some serious data tho, at least. Basically, PG is sequentially scanning
through all of the tables in your partitioning setup. What is
constraint_exclusion set to? What version of PG is this? Do the
results og this query look at all correct to you?
Have you considered an index on elevation, btw? How many records in
that city table are there and how many are actually in that range?
In response to
pgsql-performance by date
|Next:||From: David Jarvis||Date: 2010-05-21 00:19:06|
|Subject: Re: Optimize date query for large child tables: GiST or GIN?|
|Previous:||From: Stephen Frost||Date: 2010-05-20 21:19:19|
|Subject: Re: Optimize date query for large child tables: GiST orGIN?|