Re: Super Optimizing Postgres

> Does sort memory come out of shared? I don't think so (would it
> need too?), but "Cache Size and Sort Size " seems to imply that
> it does.

Sort comes from per-backend memory, not shared.  Of course, both
per-backend and shared memory come from the same pool of RAM, if that's
what you mean.  Could it be made clearer?

> Also, you don't go into the COST variables. If what is documented
> about them is correct, they are woefully incorrect with a modern
> machine.

You mean:
	
	#random_page_cost = 4
	#cpu_tuple_cost = 0.01
	#cpu_index_tuple_cost = 0.001
	#cpu_operator_cost = 0.0025

Thos are relative, of course.  We are always looking for better numbers.

> Would a 1.3 ghz Athlon really have a cpu_operator_cost of 0.0025?
> That would imply that that computer could process 2500 conditionals
> in the time it would take to make a sequential read. If Postgres
> is run on a 10K RPM disk vs a 5.4K RPM disk on two different
> machines with the same processor and speed, these numbers can't
> hope to be right, one should be about twice as high as the other.

Again, are the correct relative to each other.

> That said, do these numbers really affect the planner all that
> much?

Sure do effect the planner.  That is how index scan vs sequential and
join type are determined.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026