hey, We see a fair number of incorrectly chosen BitmapAnd plans in the wild at Faraday... enough that googling the problem ends up at our old posts to this mailing list 😀. An attractive solution was proposed by Jeff Janes [1] - *cost += 0.1 * cpu_operator_cost * path->rows; + *cost += 6 * cpu_operator_cost * path->rows; It appears this constant hasn't been changed for 7 years [2]. Is there any reason not to at least adjust this up by a factor of 2? 10? If Jeff is right and 6 is closer to ideal, then 0.1 must be _way_ too low? Thanks, Seamus [1] https://www.postgresql.org/message-id/flat/CAMkU%3D1yV7WQLetrCVPqn%3DdTPdNzW3JD29ZsK0zJmgzO2tdcx-Q%40mail.gmail.com#aa3b3316cbe44fb3fd913ce019a86bb8 [2] https://github.com/postgres/postgres/blame/master/src/backend/optimizer/path/costsize.c#L1056 -- Seamus Abshere, SCEA +598 9954 9954 https://www.faraday.io https://github.com/seamusabshere https://linkedin.com/in/seamusabshere
