| From: | Kaloyan Iliev Iliev <kaloyan(at)digsys(dot)bg> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Change query join order |
| Date: | 2010-01-20 16:06:51 |
| Message-ID: | 4B572A1B.50706@digsys.bg |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Thanks You,<br>
I changed the random_page_cost to 2 and the query plan has changed and
speeds up.<br>
I will check the other queries but I think I will leave it at this
value.<br>
<br>
Thank you again.<br>
Kaloyan Iliev<br>
<br>
</tt><br>
Robert Haas wrote:
<blockquote
cite="mid:603c8f071001081155w3b7b8042s362837542cfbc42b(at)mail(dot)gmail(dot)com"
type="cite">
<pre wrap="">On Fri, Jan 8, 2010 at 2:23 PM, Tom Lane <a class="moz-txt-link-rfc2396E" href="mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us"><tgl(at)sss(dot)pgh(dot)pa(dot)us></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">If the other plan does turn out to be faster (and I agree with Tom
that there is no guarantee of that), then one thing to check is
whether seq_page_cost and random_page_cost are set too high. If the
data is all cached, the default values of 4 and 1 are three orders of
magnitude too large, and they should also be set to equal rather than
unequal values.
</pre>
</blockquote>
<pre wrap="">Tweaking the cost parameters to suit your local situation is the
recommended cure for planner misjudgments; but I'd recommend against
changing them on the basis of only one example. You could easily
find yourself making other cases worse. Get a collection of common
queries for your app and look at the overall effects.
</pre>
</blockquote>
<pre wrap=""><!---->
No argument, and well said -- just trying to point out that the
default values really are FAR too high for people with databases that
fit in OS cache.
...Robert
</pre>
</blockquote>
</body>
</html>
| Attachment | Content-Type | Size |
|---|---|---|
| unknown_filename | text/html | 1.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Carlo Stonebanks | 2010-01-20 20:03:27 | Re: New server to improve performance on our large and busy DB - advice? |
| Previous Message | Matthew Wakeling | 2010-01-20 13:38:50 | Re: a heavy duty operation on an "unused" table kills my server |