I don’t have a database running the versions you are, but what I’ve had to do
to get around thing like is it to write the query something like this:
WITH orderids AS (
SELECT ‘546111’ AS orderid
UNION
SELECT orderid
FROM orderstotrans
WHERE transid IN ('546111')
)
select orders.orderid
FROM
On Fri, 2 Dec 2022 at 12:21, Justin Pryzby wrote:
> Could you show explain analyze ?
>
> Show the size of the table and its indexes
> And GUC settings
> And the "statistics" here:
>
> https://wiki.postgresql.org/wiki/Slow_Query_Questions#Statistics:_n_distinct.2C_MCV.2C_histogram
> Maybe on both
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
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:
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
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
