:* Chris Hoover
*Cc :* pgsql-performance@lists.postgresql.org
*Objet :* 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
ql.org
<mailto:pgsql-performance@lists.postgresql.org>
Objet : Re: Forced to use UNION ALL when having multiple ANY operators and
ORDER BY LIMIT
I normally create my indexes to match the where clause of the query. While
technically, it should not matter, I find a lot of time, it does.
I wou
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 multiple A
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
I normally create my indexes to match the where clause of the query. While
technically, it should not matter, I find a lot of time, it does.
I would create an index on (status, sender_reference, sent_at) and see if the
improves your query performance.
SELECT *
FROM docs
WHERE status IN ('dra
when having multiple ANY operators and
ORDER BY LIMIT
On Mon, Jun 12, 2023 at 1:17 PM benoit 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 perform
On Mon, Jun 12, 2023 at 1:17 PM benoit 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 e
