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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Maria L. Wilson"
Дата:
Сообщение: Re: help speeding up a query in postgres 8.4.5
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: help speeding up a query in postgres 8.4.5