Re: [HACKERS] 200 = 199 + 1?

I wrote: > I experimented a bit with the attached patch, which modifies > eqjoinsel_semi in two ways. First, if the number-of-distinct-values > estimate for the inner rel is just a default rather than having any > real basis, it replaces it with inner_rel->rows, effectively assuming > that the

Re: [HACKERS] 200 = 199 + 1?

Marko Tiikkaja writes: > On Wed, Sep 27, 2017 at 5:45 PM, Tom Lane wrote: >> Looking at it another way, the main thing that the combination of hashagg >> outer path + indexscan inner path knows that eqjoinsel_semi didn't account >> for is that there's a unique

Re: [HACKERS] 200 = 199 + 1?

On Wed, Sep 27, 2017 at 5:45 PM, Tom Lane wrote: > Marko Tiikkaja writes: > > I wonder if the nested loop shouldn't have some kind of a cap on its own > > estimate if it's wildly off of what you'd get by multiplying the child > > nodes' estimates with each

Re: [HACKERS] 200 = 199 + 1?

Marko Tiikkaja writes: > I just came across this very peculiar behavior: I think this is a consequence of the clamping + fallback logic in eqjoinsel_semi. The planner has no info about the inner select's result, except it can see the LIMIT clause so it uses that as a rowcount

[HACKERS] 200 = 199 + 1?

Hi, I just came across this very peculiar behavior: =# create table foo(id int primary key); CREATE TABLE =# insert into foo select generate_series(1, 100); INSERT 0 100 =# set enable_hashjoin to false; set enable_mergejoin to false; SET SET =# explain select * from foo where id in