Re: Query-Planer from 6seconds TO DAYS - Mailing list pgsql-performance

From Böckler Andreas
Subject Re: Query-Planer from 6seconds TO DAYS
Date
Msg-id 4818E807-E940-44F2-B10E-75038A82945C@boeckler.org
Whole thread Raw
In response to Re: Query-Planer from 6seconds TO DAYS  ("ktm@rice.edu" <ktm@rice.edu>)
Responses 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>)
List 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 by date:

Previous
From: "ktm@rice.edu"
Date:
Subject: Re: Query-Planer from 6seconds TO DAYS
Next
From: Alberto Marchesini
Date:
Subject: BAD performance with enable_bitmapscan = on with Postgresql 9.0.X (X = 3 and 10)