On Sun, 16 May 2021, 12:15 am Luca Ferrari, <fluca1978@xxxxxxxxx> 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
