From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Gaetano Mendola" <mendola(at)bigfoot(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: cpu_tuple_cost WRONG -> After an "analyze" or "vacuum full" indexes are not used anymore!!! |
Date: | 2002-07-28 17:22:02 |
Message-ID: | 11600.1027876922@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Gaetano Mendola" <mendola(at)bigfoot(dot)com> writes:
> I'm going to set the parameter cpu_tuple_cost = 0.1 to
> my server, I'm wrong ?
This seems very excessively high. 1.0 corresponds to one disk read,
which is in the several-milliseconds range on most modern systems.
You're essentially claiming that your CPU requires about a millisecond
for per-tuple overhead, which is way off base (unless you're using
an 8086 or some such...) My feeling is that the default value of 0.01
is already on the high side, and getting more so as CPUs get faster
compared to disks.
It's always possible to force the optimizer to choose "the right answer"
in one particular case by pushing out some parameter setting far beyond
the reasonable range, but I think you'll find that this answer breaks
more stuff than it fixes.
A saner way of tweaking the index-vs-seqscan costs is to reduce
random_page_cost a little --- the default is 4.0 which may be on the
high side. (But don't push it below 1.0.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Ramsey | 2002-07-28 20:01:46 | Re: Multiple Postmasters on Beowulf cluster |
Previous Message | stefan | 2002-07-28 16:52:21 | Re: [GENERAL] The best book |