Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT

No it is not. But do you think there is an impact here? Le 18/06/2023 à 23:23, msal...@msym.fr a écrit : Hi, Do you really need to do “select *”? In other words, is it necessary to have all columns in the result? /Michel SALAIS/ *De :*benoit *Envoyé :* lundi 12 juin 2023 23:35 *À

RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT

This new index is used but still the read is 230mb. https://explain.dalibo.com/plan/b0f28a9e8a136afd De : Chris Hoover Envoyé : lundi 12 juin 2023 22:55 À : benoit Cc : pgsql-performance@lists.postgresql.org Objet : Re: Forced to use UNION ALL when having

RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT

Sadly it doesn't help to disable indexscan. The plan : https://explain.dalibo.com/plan/3b3gfce5b29c3hh4 De : Peter Geoghegan Envoyé : lundi 12 juin 2023 22:34:50 À : benoit Cc : pgsql-performance@lists.postgresql.org Objet : Re: Forced to use UNION ALL

Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT

Hello I have a database with few 60gb tables. Tables rows are requested with multiple ANY or IN operators. I am not able to find an easy way to make DB able to use indexes. I often hit the index, but see a a spike of 200mb of IO or disk read. I am using version 13 but soon 14. I wrote a rep