SV: bad plan using nested loops

> Johan Fredriksson writes: > > Bad plan: https://explain.depesz.com/s/avtZ > > Good plan: https://explain.depesz.com/s/SJSt > > Any suggestions on how to make the planner make better decisions for > > this query? > > Core of the problem looks to be the misestimation here: > >Index Only

Re: effective_io_concurrency on EBS/gp2

On Wed, Jan 31, 2018 at 11:21 PM, hzzhangjiazhi wrote: > HI > > I think this parameter will be usefull when the storage using RAID > stripe , otherwise turn up this parameter is meaningless when only has one > device。 Not at all. Especially on EBS, where keeping a relatively full queue is ne

Re: bad plan using nested loops

Johan Fredriksson writes: > Bad plan: https://explain.depesz.com/s/avtZ > Good plan: https://explain.depesz.com/s/SJSt > Any suggestions on how to make the planner make better decisions for > this query? Core of the problem looks to be the misestimation here: Index Only Scan using shredd

Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used

Hi, I am using Postgres version 9.4.4 on a Mac machine. I have 2 queries that differ only in the order by clause. One of it has 'nulls last' and the other one does not have it. The performance difference between the two is considerable. The slower of the two queries is SELECT wos.notificatio

bad plan using nested loops

Hello! I brought this issue up about two years ago but without getting any real explanation or solution. The problem is that PostgreSQL does really bad plans using nested loops. With "enable_nestloop = 0" the same query is run about 20 times faster. The sugested solution I got back then was to up