On Sun, 16 May 2021, 12:15 am Luca Ferrari, <fluca1978@gmail.com> wrote:
> So far so good, but if I disable seqscan I would expect the planner to
> choose the primary key index, because that "should be" the preferred
> way to access the table.
> On the other hand, the planner enables JIT machinery and executes
> again a seqsca.
The answer is fairly simple, the planner just never considers using
the primary key index as there are no possible cases where it would be
useful. There are no quals it can help filter and there is no
ordering require that it can help provide presorted input for. If
you'd added an ORDER BY pk, you'll notice the planner does consider
the index and it does come out much cheaper than the penalised seq
scan. So the planner had no choice but to use the seqscan.
You should also be aware that the majority of the time when you
disable a given planner node that we only just add a large startup
cost penalty when costing paths for that node type. There are a
handful of nodes that are hard disabled. The reason we just add the
large penalty rather than stop that node it being used is that in many
cases we'd just fail to produce a plan due to there being no other
means to get the required results.
As for JIT being enabled. The query's cost is above jit_above_cost,
so JIT is enabled. The reason or that is that enable_seqscan TO off
added the startup penalty which pushed the plan's cost well above the
jit threshold.
David