haven't tested a composite index
invsensor is 2,003,980 rows and 219MB
granver is 5,138,730 rows and 556MB
the machine has 32G memory
seq_page_cost, random_page_costs & effective_cache_size are set to the
defaults (1,4, and 128MB) - looks like they could be bumped up.
Got any recommendations?
Maria
On 5/10/11 1:59 PM, Robert Haas wrote:
[ woops, accidentally replied off-list, trying again ]
On Tue, May 10, 2011 at 1:47 PM, Maria L. Wilson
<Maria.L.Wilson-1@xxxxxxxx> 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
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
