Ronuk Raval writes:
> We've been working around the problem by rewriting queries to use UNION
> instead.
Yeah, that. The real issue here is that the seqscan and indexscan plans
both suck, because they will both run that sub-select for every row
in the table. The index-only plan might fetch few
On Thu, Dec 1, 2022 at 8:21 PM Justin Pryzby 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
On Fri, Dec 02, 2022 at 11:52:19AM +1100, Paul McGarry wrote:
> Hi there,
>
> I'm wondering if anyone has any insight into what might make the database
> choose a sequential scan for a query (table defs and plan below) like :
> Plan - seq scan of table:
> =
> > explain select orders.orderid F
Hi there,
I'm wondering if anyone has any insight into what might make the database
choose a sequential scan for a query (table defs and plan below) like :
SELECT orders.orderid FROM orders
WHERE (
orders.orderid IN ('546111')
OR
orders.orderid IN (select orderid FROM orderstotrans WHERE (tran
On 2022-11-30 We 11:36, Tom Lane wrote:
> Andres Freund writes:
>> On November 30, 2022 3:47:32 AM PST, Andrew Dunstan
>> wrote:
>>> I think Alvaro's point is that it would have been better to work out
>>> these wrinkles before turning on JIT by default. Based on anecdotal
>>> reports from the
