Re: Query-Planer from 6seconds TO DAYS

From: "Kevin Grittner" <kgrittn(at)mail(dot)com>
To: "Böckler Andreas" <andy(at)boeckler(dot)org>, "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Query-Planer from 6seconds TO DAYS
Date: 2012-10-25 18:22:26
Message-ID: 20121025182226.306900@gmx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Böckler Andreas wrote:

> I've played with seq_page_cost and enable_seqscan already, but you
> have to know the right values before SELECT to get good results ;)

The idea is to model actual costs on your system.  You don't show
your configuration or describe your hardware, but you show an
estimate of retrieving over 4000 rows through an index and describe a
response time of 4 seconds, so you must have some significant part of
the data cached.

I would see how the workload behaves with the following settings:

effective_cache_size = <your shared_buffers setting plus what the OS
                       shows as cached pages>
seq_page_cost = 1
random_page_cost = 2
cpu_tuple_cost = 0.05

You can set these in a session and check the plan with EXPLAIN. Try
various other important important queries with these settings and
variations on them. Once you hit the right factors to model your
actual costs, the optimizaer will make better choices without needing
to tinker with it each time.

-Kevin

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Böckler Andreas 2012-10-26 14:37:33 Re: Query-Planer from 6seconds TO DAYS
Previous Message Jeff Janes 2012-10-25 16:20:56 Re: Query-Planer from 6seconds TO DAYS