Too many BitmapAnds in the wild

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