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

Re: Optimize date query for large child tables: GiST orGIN?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: David Jarvis <thangalin(at)gmail(dot)com>
Cc: Matthew Wakeling <mnw21(at)cam(dot)ac(dot)uk>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimize date query for large child tables: GiST orGIN?
Date: 2010-05-20 21:30:29
Message-ID: 20100520213029.GQ21875@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-performance
* 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?

	Thanks,

		Stephen

In response to

Responses

pgsql-performance by date

Next:From: David JarvisDate: 2010-05-21 00:19:06
Subject: Re: Optimize date query for large child tables: GiST or GIN?
Previous:From: Stephen FrostDate: 2010-05-20 21:19:19
Subject: Re: Optimize date query for large child tables: GiST orGIN?

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