Re: Extremely slow HashAggregate in simple UNION query

2019-08-21 Thread Pavel Stehule
čt 22. 8. 2019 v 3:11 odesílatel Jeff Janes napsal: > On Tue, Aug 20, 2019 at 11:12 AM Felix Geisendörfer > wrote: > ... > > >> [1] My actual query had bad estimates for other reasons (GIN Index), but >> that's another story. The query above was of course deliberately designed >> to have bad es

Re: Extremely slow HashAggregate in simple UNION query

2019-08-21 Thread Jeff Janes
On Tue, Aug 20, 2019 at 11:12 AM Felix Geisendörfer wrote: ... > [1] My actual query had bad estimates for other reasons (GIN Index), but > that's another story. The query above was of course deliberately designed > to have bad estimates. > As noted elsewhere, v12 thwarts your attempts to deli

Re: Erratically behaving query needs optimization

2019-08-21 Thread Luís Roberto Weck
Em 21/08/2019 04:30, Barbu Paul - Gheorghe escreveu: I wonder how I missed that... probabily because of the "WHERE" clause in what I already had. I indexed by scheduler_task_executions.device_id and the new plan is as follows: https://explain.depesz.com/s/cQRq Can it be further improved? Limit

Re: Erratically behaving query needs optimization

2019-08-21 Thread Barbu Paul - Gheorghe
I wonder how I missed that... probabily because of the "WHERE" clause in what I already had. I indexed by scheduler_task_executions.device_id and the new plan is as follows: https://explain.depesz.com/s/cQRq Can it be further improved? Limit (cost=138511.45..138519.36 rows=2 width=54) (actual t