David Brown wrote:
You might want to reduce random_page_cost a little.


Keep in mind that your test case is small enough to fit in RAM and
is probably not reflective of what will happen with larger tables.


I am also running 8.0 rc1 for Windows. Despite many hours spent
tweaking various planner cost constants, I found little effect on
cost estimates. Even reducing random_page_cost from 4.0 to 0.1 had
negligible impact and failed to significantly influence the planner.

I'm not sure setting random_page_cost below 1.0 makes much sense.

Increasing the statistics target for the last_name column to 250 or
so *may* help, at least if you're only selecting one name at a time.

Not going to do anything in this case. The planner is roughly right about how many rows will be returned, it's just not expecting everything to be in RAM.


That's the standard advice around here and the only thing I've found
useful. Half the threads in this forum are about under-utilized
indexes. It would be great if someone could admit the planner is
broken and talk about actually fixing it!

Not sure I agree here - when the stats are accurate, you can get the planner to make near-optimal choices most of the time. Is there any particular pattern you've seen?


I'm unconvinced that the planner only favours sequential scans as
table size decreases. In my experience so far, larger tables have the
same problem only it's more noticeable.

Hmm - assuming your statistics are good, this would suggest the other cost settings just aren't right for your hardware.


The issue hits PostgreSQL harder than others because of its awful
sequential scan speed, which is two to five times slower than other
DBMS. The archives show there has been talk for years about this, but
it seems, no solution. The obvious thing to consider is the block
size, but people have tried increasing this in the past with only
marginal success.

Must admit this puzzles me. Are you saying you can't saturate your disk I/O? Or are you saying other DBMS store records in 0.5 to 0.2 times less space than PG?


--
  Richard Huxton
  Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to