Re: Query-Planer from 6seconds TO DAYS

Поиск
Список
Период
Сортировка
От ktm@rice.edu
Тема Re: Query-Planer from 6seconds TO DAYS
Дата
Msg-id 20121026153049.GC2872@aart.rice.edu
обсуждение исходный текст
Ответ на Re: Query-Planer from 6seconds TO DAYS  (Böckler Andreas <andy@boeckler.org>)
Список pgsql-performance
On Fri, Oct 26, 2012 at 05:15:05PM +0200, Böckler Andreas wrote:
> 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
>

Hi Andy,

You can set them per tablespace. Maybe you could put the appropriate tables
that need the higher costing on the same one.

Regards,
Ken


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

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