Re: Extremely slow HashAggregate in simple UNION query

Andres Freund <[email protected]>
Newsgroups gmane.comp.db.postgresql.performance
Message-ID <[email protected]>
Hi,

On 2019-08-20 19:55:56 +0200, Felix Geisendörfer wrote:
> > On 20. Aug 2019, at 19:32, Andres Freund <[email protected]> wrote:
> > FWIW, that's not a mis-estimate I'm getting on master ;).  Obviously
> > that doesn't actually address your concern...
> 
> I suppose this is thanks to the new optimizer support functions
> mentioned by Michael and Pavel?

Right.


> > Under-sizing the hashtable just out of caution will have add overhead to
> > a lot more common cases. That requires copying data around during
> > growth, which is far far from free. Or you can use hashtables that don't
> > need to copy, but they're also considerably slower in the more common
> > cases.
> 
> How does PostgreSQL currently handle the case where the initial hash
> table is under-sized due to the planner having underestimated things?
> Are the growth costs getting amortized by using an exponential growth
> function?

Yes. But that's still far from free.

Greetings,

Andres Freund
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.