Re: trouble with (lack of) indexing

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> Or am I just barking up a dead horse here since I'm now thinking it
> might be nice to include information about potential indexes and at
> what row count from them it's decided a seqscan is better.

There is no "row count at which it's decided a seqscan is better".
The planner does cost estimates and picks the plan with the lowest
estimated cost, so all the behavior is emergent from the cost
estimation equations.

I have not been able to think of any output format that would show
rejected plan estimates without being so verbose as to be unreadable
--- except in the most trivial cases, there are a *lot* of rejected
plans, and the planner has no idea which of them might be interesting
to a human. (You can try defining OPTIMIZER_DEBUG if you want to see
it in action, but I don't think the output is very useful in practice.)
What's worse is that (a) the only reason why you'd care is if the
estimates are wrong, but (b) there is no way to tell anything about the
actual cost that might be associated with a rejected plan fragment.
To compare estimates to reality you really have to arrange for the plan
to be the selected one, so that you can run it.

regards, tom lane