| From: | Ronuk Raval <ronuk(dot)raval(at)gmail(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Paul McGarry <paul(at)paulmcgarry(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Odd Choice of seq scan |
| Date: | 2022-12-02 05:37:50 |
| Message-ID: | CAPhHnhr7NZdR7J=4H4ndsfXjPP6-V8VDtiUrcW_=iWcrhQXGYg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Dec 1, 2022 at 8:21 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> Could you show explain analyze ?
>
> Maybe on both a well-behaving instance and a badly-beving instance.
Apologies for barging into this thread with a potentially unrelated
"me too" but here's a similar OR-causes-seqscan from 2018:
https://www.postgresql.org/message-id/CAPhHnhpc6bdGbRBa9hG7FQiKByVqR3s37VoY64DSMUxjeJGOjQ%40mail.gmail.com
I don't have other versions handy but can confirm that the problem
exists on Postgres 11.17 (dated but newer than the 10.1 in that post).
We've been working around the problem by rewriting queries to use UNION instead.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-12-02 06:16:10 | Re: Odd Choice of seq scan |
| Previous Message | Justin Pryzby | 2022-12-02 01:21:24 | Re: Odd Choice of seq scan |