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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026