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,
Pennsylvania19026