Re: Extremely slow HashAggregate in simple UNION query

2019-08-20 Thread Michael Lewis
I believe this would be relevant- https://www.cybertec-postgresql.com/en/optimizer-support-functions/ It seems there is hope down the road to improve those estimates.

Re: Extremely slow HashAggregate in simple UNION query

2019-08-20 Thread Andres Freund
Hi, On 2019-08-20 19:55:56 +0200, Felix Geisendörfer wrote: > > On 20. Aug 2019, at 19:32, Andres Freund 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 fun

Re: Extremely slow HashAggregate in simple UNION query

2019-08-20 Thread Felix Geisendörfer
Hi, > On 20. Aug 2019, at 19:32, Andres Freund wrote: > > Hi, > > On 2019-08-20 17:11:58 +0200, Felix Geisendörfer wrote: >> >> HashAggregate (cost=80020.01..100020.01 rows=200 width=8) (actual >> time=19.349..23.123 rows=1 loops=1) > > FWIW, that's not a mis-estimate I'm getting on mas

Re: Extremely slow HashAggregate in simple UNION query

2019-08-20 Thread Andres Freund
Hi, On 2019-08-20 17:11:58 +0200, Felix Geisendörfer wrote: > today I debugged a query that was executing about 100x slower than expected, > and was very surprised by what I found. > > I'm posting to this list to see if this might be an issue that should be > fixed in PostgreSQL itself. > > Belo

Re: Extremely slow HashAggregate in simple UNION query

2019-08-20 Thread Pavel Stehule
út 20. 8. 2019 v 17:12 odesílatel Felix Geisendörfer napsal: > Hi all, > > today I debugged a query that was executing about 100x slower than > expected, and was very surprised by what I found. > > I'm posting to this list to see if this might be an issue that should be > fixed in PostgreSQL itse

Extremely slow HashAggregate in simple UNION query

2019-08-20 Thread Felix Geisendörfer
Hi all, today I debugged a query that was executing about 100x slower than expected, and was very surprised by what I found. I'm posting to this list to see if this might be an issue that should be fixed in PostgreSQL itself. Below is a simplified version of the query in question: SET work_me

Re: Erratically behaving query needs optimization

2019-08-20 Thread MichaelDBA
Yes, adding another index might help reduce the number of rows filtered --> Rows Removed by Filter: 1308337 Also, make sure you run vacuum analyze on this query. Regards, Michael Vitale Luís Roberto Weck wrote on 8/20/2019 10:58 AM: Em 20/08/2019 10:54, Barbu Paul - Gheorghe escreveu: Hello,

Re: Erratically behaving query needs optimization

2019-08-20 Thread Luís Roberto Weck
Em 20/08/2019 10:54, Barbu Paul - Gheorghe escreveu: Hello, I'm running "PostgreSQL 11.2, compiled by Visual C++ build 1914, 64-bit" and I have a query that runs several times per user action (9-10 times). The query takes a long time to execute, specially at first, due to cold caches I think, but

Erratically behaving query needs optimization

2019-08-20 Thread Barbu Paul - Gheorghe
Hello, I'm running "PostgreSQL 11.2, compiled by Visual C++ build 1914, 64-bit" and I have a query that runs several times per user action (9-10 times). The query takes a long time to execute, specially at first, due to cold caches I think, but the performance varies greatly during a run of the app