Re: BUG #19708: Hash Join becomes about 300x slower with higher work_mem

On Tue, Sep 22, 2026 at 12:31 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:

>
> > Indeed. So I think this is an uninteresting contrived case.
>
> I agree the reproducer is contrived, and that assuming
> 10 pages for a never vacuumed table is the right call.
>
> My concern is that ANALYZE does not always get us out of it. The
> n_distinct estimator is known to undershoot on long tailed columns.
>
> I did a mini benchmark:
>
> Take a 5M row orders table where half the rows come from 1000 big
> customers
> and half from one time customers. Right after ANALYZE it gets n_distinct
> 31846, against a true value of 2.5M. A join of two such tables is
> estimated at 780M rows and returns 2.5M. That is one join, and each
> further join multiplies the error.
>

True, that sort of error should compound over multiple joins, and so the
number
of rows.

Could you include your script?

> So the same shape comes out of fresh statistics on an ordinary schema,
> and the extra cost only appeared in 18. That is why I think it is worth
> handling.
>

Regards,
Alexandre