Re: help speeding up a query in postgres 8.4.5
От | Maria L. Wilson |
---|---|
Тема | Re: help speeding up a query in postgres 8.4.5 |
Дата | |
Msg-id | 4DC981D9.3070008@nasa.gov обсуждение исходный текст |
Ответ на | Re: help speeding up a query in postgres 8.4.5 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: help speeding up a query in postgres 8.4.5
|
Список | pgsql-performance |
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@nasa.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
В списке pgsql-performance по дате отправления: