From: | benoit <benoit(at)hopsandfork(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT |
Date: | 2023-06-12 20:50:50 |
Message-ID: | 6551f5840dc44882bdac1475526ebfc9@hopsandfork.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Sadly it doesn't help to disable indexscan. The plan : https://explain.dalibo.com/plan/3b3gfce5b29c3hh4
________________________________
De : Peter Geoghegan <pg(at)bowt(dot)ie>
Envoyé : lundi 12 juin 2023 22:34:50
À : benoit
Cc : pgsql-performance(at)lists(dot)postgresql(dot)org
Objet : Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
On Mon, Jun 12, 2023 at 1:17 PM benoit <benoit(at)hopsandfork(dot)com> wrote:
> Is there a misusage of my indexes?
>
> Is there a limitation when using ANY or IN operators and ordered LIMIT behind?
It's complicated. Do you find that you get satisfactory performance if
you force a bitmap index scan? In other words, what is the effect of
"set enable_indexscan = off" on your original query? Does that speed
up execution at all? (I think that this approach ought to produce a
plan that uses a bitmap index scan in place of the index scan, without
changing anything else.)
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Hoover | 2023-06-12 20:55:22 | Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT |
Previous Message | Peter Geoghegan | 2023-06-12 20:34:50 | Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT |