Re: Bogus nestloop rows estimate in 8.4.7

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bogus nestloop rows estimate in 8.4.7
Date: 2012-05-29 16:35:57
Message-ID: 13181.1338309357@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Hmm, but isn't this a case of the left hand not knowing what the right
> hand is doing? I mean, somehow we have enough information to estimate
> that the index scans on b{1,2,3} are going to produce 2 rows per
> execution, but having figured that out (correctly) we then proceed to
> ignore it.

Well, if you wanted to do that, what it would amount to is saying that
the estimated size of the join relation is going to change depending on
which implementation path you consider for it, which would be a mess,
not to mention mathematically silly. You could possibly choose to use
the size from one path that you believe more than the other paths, but
on what grounds will you make that choice; and then will you go back and
change your estimates for the paths you already did costing for?

We have bitten off some of this for cases involving join relations that
are still parameterized, but I don't think it makes much sense for
non-parameterized join paths. And even in the parameterized case, we
are careful to use the same size estimate for all implementation paths
that yield the same parameterization.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-29 16:42:53 Re: Issues with MinGW W64
Previous Message Robert Haas 2012-05-29 16:22:18 Re: Bogus nestloop rows estimate in 8.4.7