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
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 |