Chris Cleveland <ccleve+github@dieselpoint.com> writes:
> I'm developing a new index access method. Sometimes the planner uses it and
> sometimes it doesn't. I'm trying to debug the process to understand why the
> index does or doesn't get picked up.
> Is there a way to dump all of the query plans that the planner considered,
> along with information on why they were rejected? EXPLAIN only gives info
> on the plan that was actually selected.
What you can do is "set enable_seqscan = off", then EXPLAIN.
If you get an indexscan where before you did not, then you have
a costing problem, ie use of index is estimated as more costly
than a seqscan. (This is not necessarily wrong, particularly
if you make the rookie mistake of testing with a tiny table.)
If you still get a seqscan, then the planner doesn't think the
query conditions match the index, and you have a different
problem to solve.
If you really want to see all the paths, you could do it with
gdb --- set a breakpoint at add_path and inspect the structs
that get passed to it. I doubt that will give you much
additional info for this problem. However, if (as seems
likely) it's a costing problem, then you may well end up
stepping through your amcostestimate function to see where
it's going off the rails; so learning to gdb the backend
will be well worth your time anyway.
regards, tom lane