Re: Failure to reordering in case of a lateral join in combination with a left join (not inner join) resulting in suboptimal nested loop plan

Peter Billen writes: > For some reason I cannot explain we now end up with a nested loop, instead > an hash join. The fairly trivial introduction of `t(int)` messes up with > reordering, but I fail to see why. I traced through this and determined that it's got nothing to do with function inlining

Failure to reordering in case of a lateral join in combination with a left join (not inner join) resulting in suboptimal nested loop plan

Hi, The queries in what follows can be executed on the following fiddle: *https://dbfiddle.uk/?rdbms=postgres_10&fiddle=64542f2d987d3ce0d85bbc40ddadf7d6 * - Please note that the queries/functions might look silly/point

RE: Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans

>The problem seems to be that the actual values being used for >c400129200 and c400127400 are quite common in the dataset, so that when >considering >Filter: ... (c400129200 = '0'::citext) AND (c400127400 = 'DATASET1M'::citext) >the planner makes a roughly correct assessment that there are a lot