pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Benjamin Coutu <ben.coutu@zeyos.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Unclamped row estimates whith OR-ed subplans
Date: Fri, 19 Jun 2020 12:04:47 -0400
Message-ID: <1666226.1592582687@sss.pgh.pa.us> (raw)
In-Reply-To: <20200619151232.7F3285FB26@mx.zeyos.com>
References: <20200619151232.7F3285FB26@mx.zeyos.com>

"Benjamin Coutu" <ben.coutu@zeyos.com> writes:
> please consider the following SQL query:

> SELECT * FROM "transactions" WHERE 
> 	"account" IN (SELECT "ID" FROM "accounts" WHERE "name" ~~* '%test%') OR
> 	"contract" IN (SELECT "ID" FROM "contracts" WHERE "name" ~~* '%test%')

> This yields the following plan on Postgres 11:

> Seq Scan on transactions  (cost=67.21..171458.03 rows=1301316 width=1206)
>   Filter: ((hashed SubPlan 1) OR (hashed SubPlan 2))
>   SubPlan 1
>     ->  Bitmap Heap Scan on accounts  (cost=33.36..61.16 rows=46 width=4)
>           Recheck Cond: ((name)::text ~~* '%test%'::text)
>           ->  Bitmap Index Scan on s_accounts  (cost=0.00..33.35 rows=46 width=0)
>                 Index Cond: ((name)::text ~~* '%test%'::text)
>   SubPlan 2
>     ->  Seq Scan on contracts  (cost=0.00..5.93 rows=5 width=4)
>           Filter: ((name)::text ~~* '%test%'::text)

> So the where clause of this query has just two subplans OR-ed together, one is estimated to yield 46 rows and one is estimated to yield 5 rows.
> I'd expect the total rows for the seqscan to be estimated at 46 then, following the logic that rows_seqscan = max(rows_subplan1, rows_subplan2). As you can see, the optimizer estimates a whopping 1301316 rows instead.

No.  The subplan estimates are for the number of rows produced by one
execution of the subplan, ie the numbers of "accounts" or "contracts"
rows that match those inner WHERE conditions.  This has very little
a-priori relationship to the number of "transactions" rows that will
satisfy the outer WHERE condition.  If we knew that transactions.account
and transactions.contract were unique columns, then we might be able
to say that there shouldn't be more than one outer match per subplan
result row ... but you didn't say that, and it seems unlikely.

(Having said that, I think that the estimates for these cases very
possibly are quite stupid.  But that doesn't mean that 46+5 would
be the right answer.)

			regards, tom lane





view thread (8+ messages)  latest in thread

Message-ID: <1666226.1592582687@sss.pgh.pa.us>
Permalink:  ../1666226.1592582687@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1666226.1592582687@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, ben.coutu@zeyos.com
  Subject: Re: Unclamped row estimates whith OR-ed subplans
  In-Reply-To: <1666226.1592582687@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox