On 9.5 beta it still works similar. Did You see my last reply?:
I've done it already. I've also already check rewrited query. No changes. But i have a idea. There is generated base and there are "normal" shipment_order_item with 3 - 100 maybe 10000 shipment_order_sub_item but one has 3 992 102. Could it be a problem?
If yes that is my bad to ask You because I'belive there will not occur in production and counting could bye match faster.
I think it could be this problem. Additional I checked number of sub items and there is 6 items and 5 contains 2 sub items and 1 contains 3 992 102 sub items. For me that is only "not normal" data problem and i think it will be working correct when data is normal.
P.S. I checked all cases on 9.5 and there are no differences.
On 2015-12-14 11:45:27 +0000, sienkomarcin@gmail.com wrote: > The following bug has been logged on the website: > > Bug reference: 13817 > Logged by: Marcin_S > Email address: sienkomarcin@gmail.com > PostgreSQL version: 9.4.5 > Operating system: Windows 7 x64 > Description: > > Hi, > > First sorry for not completed last bug (browser handle it too fast :). Here > is complete version: > > > I've check todo list but i can't find exact problem i'm reporting. It seems > like query planner fires not needed sequence scan by all rows in table when > only a few rows were picked.
Can you try this with version 9.5 (currently in beta)? This looks very similar to a problem I reported some time ago and which is fixed in 9.5.
hp -- _ | Peter J. Holzer | I want to forget all about both belts and |_|_) | | suspenders; instead, I want to buy pants | | | hjp@hjp.at | that actually fit. __/ | http://www.hjp.at/ | -- http://noncombatant.org/