Re: Query-Planer from 6seconds TO DAYS

Поиск
Список
Период
Сортировка
От Böckler Andreas
Тема Re: Query-Planer from 6seconds TO DAYS
Дата
Msg-id 4818E807-E940-44F2-B10E-75038A82945C@boeckler.org
обсуждение исходный текст
Ответ на Re: Query-Planer from 6seconds TO DAYS  ("ktm@rice.edu" <ktm@rice.edu>)
Ответы Re: Query-Planer from 6seconds TO DAYS  ("ktm@rice.edu" <ktm@rice.edu>)
Re: Query-Planer from 6seconds TO DAYS  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-performance
Hi Ken,

Am 26.10.2012 um 16:55 schrieb ktm@rice.edu:

> Hi Andy,
>
> You have the sequential_page_cost = 1 which is better than or equal to
> the random_page_cost in all of your examples.
> It sounds like you need
> a sequential_page_cost of 5, 10, 20 or more.

You're right it was sequential_page_cost = 1 because it's really irrelevant what I do here:
set random_page_cost=2;
set seq_page_cost=5;
'2012-05-01' AND '2012-08-30' -> NESTEDLOOP
'2012-04-01' AND '2012-08-30' -> SEQSCAN

a) there will be a point, where things will go bad
 this is like patching up a roof 'till you find the next hole instead of making it right at the beginning of
constructionprocess 
b) they high seq costs might be true for that table (partition at 40gb), but not for the rest of the database
 Seqscan-Costs per table would be great.

Regards,

Andy


--
Andreas Böckler
andy@boeckler.org


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

Предыдущее
От: "ktm@rice.edu"
Дата:
Сообщение: Re: Query-Planer from 6seconds TO DAYS
Следующее
От: Alberto Marchesini
Дата:
Сообщение: BAD performance with enable_bitmapscan = on with Postgresql 9.0.X (X = 3 and 10)