| From: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> |
|---|---|
| To: | Böckler Andreas <andy(at)boeckler(dot)org> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Query-Planer from 6seconds TO DAYS |
| Date: | 2012-10-26 15:30:49 |
| Message-ID: | 20121026153049.GC2872@aart.rice.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)rice(dot)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 construction process
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2012-10-26 15:41:12 | Re: Query-Planer from 6seconds TO DAYS |
| Previous Message | Böckler Andreas | 2012-10-26 15:30:47 | Re: Query-Planer from 6seconds TO DAYS |