From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
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 17:58:19 |
Message-ID: | CAMkU=1yB4OY8T4+c677ViCP_9Rgk6HvW7wObURHT8gE0ie+uiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Oct 26, 2012 at 8:15 AM, Böckler Andreas <andy(at)boeckler(dot)org> 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
Sure. And there truly is some point at which the sequential scan
actually will become faster.
> this is like patching up a roof 'till you find the next hole instead of making it right at the beginning of construction process
We are not at the beginning of the construction process. You are
already living in the house.
Version 9.3 is currently under construction. Maybe this will be a fix
for this problem in that release. The hackers mailing list would be
the place to discuss that.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2012-10-26 17:58:57 | PSA: New Kernels and intel_idle cpuidle Driver! |
Previous Message | Kevin Grittner | 2012-10-26 15:41:12 | Re: Query-Planer from 6seconds TO DAYS |