Re: Question about Expected rows value in EXPLAIN output for Nested Loop node

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: bb ddd <nnickoloff1234(at)abv(dot)bg>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Question about Expected rows value in EXPLAIN output for Nested Loop node
Date: 2019-05-11 15:47:18
Message-ID: 32178.1557589638@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

bb ddd <nnickoloff1234(at)abv(dot)bg> writes:
> Thanks, Adrian, but i was looking for something that goes into more depth.

Use the source, Luke.

git clone git://git.postgresql.org/git/postgresql.git

Likely places to look for this purpose include

src/backend/optimizer/README
src/backend/optimizer/path/costsize.c
src/backend/optimizer/path/clausesel.c
src/backend/utils/adt/selfuncs.c

The short answer to your question is that no, the size of the join
relation is not estimated by multiplying the sizes of input paths
for some particular nestloop plan. The join size estimate is made
first and the same size is applied to all paths for the join.

In the case of a nestloop where the entire join condition was pushed
into the RHS path, you'd ideally expect that the LHS size times the
estimated size of the filtered RHS path matches the previously-made
join size estimate ... but those are different code paths using
different estimators, and since this is all very approximate and
full of heuristic guesses, sometimes they don't match very well.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jeremy Schneider 2019-05-11 16:15:07 Re: Hot Standby Conflict on pg_attribute
Previous Message Adrian Klaver 2019-05-11 13:48:04 Re: perl path issue