Re: Query much faster with enable_seqscan=0

Поиск
Список
Период
Сортировка
От Ogden
Тема Re: Query much faster with enable_seqscan=0
Дата
Msg-id D551B381-C707-43C1-A3F5-A3064F09152C@darkstatic.com
обсуждение исходный текст
Ответ на Re: Query much faster with enable_seqscan=0  (Greg Smith <greg@2ndquadrant.com>)
Ответы Re: Query much faster with enable_seqscan=0
Список pgsql-performance
On Sep 21, 2010, at 2:16 PM, Greg Smith wrote:

> Joshua D. Drake wrote:
>> PostgreSQL's defaults are based on extremely small and some would say
>> (non production) size databases. As a matter of course I always
>> recommend bringing seq_page_cost and random_page_cost more in line.
>>
>
> Also, they presume that not all of your data is going to be in memory, and the query optimizer needs to be careful
aboutwhat it does and doesn't pull from disk.  If that's not the case, like here where there's 8GB of RAM and a 7GB
database,dramatic reductions to both seq_page_cost and random_page_cost can make sense.  Don't be afraid to think
loweringbelow 1.0 is going too far--something more like 0.01 for sequential and 0.02 for random may actually reflect
realityhere. 
>

I have done just that, per your recommendations and now what took 14 seconds, only takes less than a second, so it was
certainlythese figures I messed around with. I have set: 

seq_page_cost = 0.01
random_page_cost = 0.02
cpu_tuple_cost = 0.01

Everything seems to run faster now. I think this should be fine - I'll keep an eye on things over the next few days.

I truly appreciate everyone's help.

Ogden


В списке pgsql-performance по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: GPU Accelerated Sorting
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Using Between