From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Maria(dot)L(dot)Wilson-1(at)nasa(dot)gov |
Cc: | "Wilson, Maria Louise (LARC-E301)[SCIENCE SYSTEMS AND APPLICATIONS, INC]" <m(dot)l(dot)wilson(at)nasa(dot)gov>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: help speeding up a query in postgres 8.4.5 |
Date: | 2011-05-10 17:59:11 |
Message-ID: | BANLkTi=d_ohr61DianQ7Q-23+z5fCisD9g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
[ woops, accidentally replied off-list, trying again ]
On Tue, May 10, 2011 at 1:47 PM, Maria L. Wilson
<Maria(dot)L(dot)Wilson-1(at)nasa(dot)gov> wrote:
> thanks for taking a look at this.... and it's never too late!!
>
> I've tried bumping up work_mem and did not see any improvements -
> All the indexes do exist that you asked.... see below....
> Any other ideas?
>
> CREATE INDEX invsnsr_idx1
> ON invsensor
> USING btree
> (granule_id);
>
> CREATE INDEX invsnsr_idx2
> ON invsensor
> USING btree
> (sensor_id);
What about a composite index on both columns?
> CREATE UNIQUE INDEX granver_idx1
> ON gran_ver
> USING btree
> (granule_id);
It's a bit surprising to me that this isn't getting used. How big are
these tables, and how much memory do you have, and what values are you
using for seq_page_cost/random_page_cost/effective_cache_size?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Maria L. Wilson | 2011-05-10 18:20:09 | Re: help speeding up a query in postgres 8.4.5 |
Previous Message | Pierre C | 2011-05-10 17:56:03 | Postgres NoSQL emulation |