Skip site navigation (1) Skip section navigation (2)

Re: cpu_tuple_cost WRONG -> After an "analyze" or "vacuum full" indexes are not used anymore!!!

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-admin by date

Next:From: Paul RamseyDate: 2002-07-28 20:01:46
Subject: Re: Multiple Postmasters on Beowulf cluster
Previous:From: stefanDate: 2002-07-28 16:52:21
Subject: Re: [GENERAL] The best book

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group