Обсуждение: BUG #14159: PostgreSQL 9.6 parallel scan consume very high mutex lock
VGhlIGZvbGxvd2luZyBidWcgaGFzIGJlZW4gbG9nZ2VkIG9uIHRoZSB3ZWJz aXRlOgoKQnVnIHJlZmVyZW5jZTogICAgICAxNDE1OQpMb2dnZWQgYnk6ICAg ICAgICAgIFpob3UgRGlnb2FsCkVtYWlsIGFkZHJlc3M6ICAgICAgZGlnb2Fs QDEyNi5jb20KUG9zdGdyZVNRTCB2ZXJzaW9uOiA5LjZiZXRhMQpPcGVyYXRp bmcgc3lzdGVtOiAgIENlbnRPUyA2LnggeDY0CkRlc2NyaXB0aW9uOiAgICAg ICAgCgpNeSB0ZXN0IGVudmlyb25tZW50Og0KQ2VudE9TIDYNCjY0IENPUkUg Y3B1DQoNCnRoaXMgaXMgbm90IHVzZSBwYXJhbGxlbA0KcG9zdGdyZXM9IyBh bHRlciB0YWJsZSB0X2JpdDIgc2V0IChwYXJhbGxlbF9kZWdyZWU9MCk7DQpB TFRFUiBUQUJMRQ0KVGltZTogMC4zMzUgbXMNCg0KcG9zdGdyZXM9IyBzZWxl Y3QgY291bnQoKikgZnJvbSB0X2JpdDIgOw0KICAgY291bnQgICAgDQotLS0t LS0tLS0tLS0NCiAxNjAwMDAwMDAwDQooMSByb3cpDQpUaW1lOiAxNDEzNzcu MTAwIG1zDQoNCmFuZCB0aGUgcGVyZnRvcCBpcw0KYGBgDQogICBQZXJmVG9w OiAgICAxMDc1IGlycXMvc2VjICBrZXJuZWw6MjEuNSUgIGV4YWN0OiAgMC4w JSBbMTAwMEh6IGN5Y2xlc10sIAooYWxsLCA2NCBDUFVzKQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KICAgICAgICAgICAgIHNhbXBsZXMgIHBjbnQgZnVuY3Rpb24gICAg ICAgICAgICAgICAgICAgICAgICAgRFNPDQogICAgICAgICAgICAgX19fX19f XyBfX19fXyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KICAgICAgICAg ICAgIDI0OTMuMDAgMTUuMiUgaGVhcF9nZXRuZXh0ICAgICAgICAgICAgICAg ICAgICAKL2hvbWUvZGlnb2FsL3Bnc3FsOS42L2Jpbi9wb3N0Z3JlcyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogIA0KICAg ICAgICAgICAgIDE5ODguMDAgMTIuMSUgY29weV91c2VyX2dlbmVyaWNfc3Ry aW5nICAgICAgICAKW2tlcm5lbC5rYWxsc3ltc10gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgDQogICAgICAgICAgICAgMTI2NS4wMCAgNy43JSBhZHZhbmNlX2FnZ3Jl Z2F0ZXMgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmlu L3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgDQogICAgICAgICAgICAgIDkzMS4wMCAgNS43JSBFeGVjUHJv amVjdCAgICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5 LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgDQogICAgICAgICAgICAgIDg5MS4wMCAgNS40JSBo ZWFwZ2V0cGFnZSAgICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwv cGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgDQogICAgICAgICAgICAgIDg2NC4wMCAg NS4zJSBIZWFwVHVwbGVTYXRpc2ZpZXNNVkNDICAgICAgICAgIAovaG9tZS9k aWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgDQogICAgICAgICAgICAgIDc0 NC4wMCAgNC41JSBFeGVjUHJvY05vZGUgICAgICAgICAgICAgICAgICAgIAov aG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgDQogICAgICAgICAg ICAgIDcxNy4wMCAgNC40JSBhZHZhbmNlX3RyYW5zaXRpb25fZnVuY3Rpb24g ICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgDQogICAg ICAgICAgICAgIDY5Ny4wMCAgNC4yJSBFeGVjU2NhbiAgICAgICAgICAgICAg ICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVz ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg DQogICAgICAgICAgICAgIDU4MS4wMCAgMy41JSBTZXFOZXh0ICAgICAgICAg ICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bv c3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgDQogICAgICAgICAgICAgIDU3Ni4wMCAgMy41JSBFeGVjU3RvcmVU dXBsZSAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYv YmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgDQogICAgICAgICAgICAgIDQ0Ni4wMCAgMi43JSBFeGVj Q2xlYXJUdXBsZSAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdz cWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgDQogICAgICAgICAgICAgIDM3OC4wMCAgMi4z JSBNZW1vcnlDb250ZXh0UmVzZXQgICAgICAgICAgICAgIAovaG9tZS9kaWdv YWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgDQogICAgICAgICAgICAgIDM2NC4w MCAgMi4yJSBoYXNoX3NlYXJjaF93aXRoX2hhc2hfdmFsdWUgICAgIAovaG9t ZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgDQogICAgICAgICAgICAg IDM2NC4wMCAgMi4yJSBFeGVjQWdnICAgICAgICAgICAgICAgICAgICAgICAg IAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgDQogICAgICAg ICAgICAgIDMwNy4wMCAgMS45JSBDaGVja0ZvclNlcmlhbGl6YWJsZUNvbmZs aWN0T3V0IAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgDQog ICAgICAgICAgICAgIDI5Ni4wMCAgMS44JSBmZXRjaF9pbnB1dF90dXBsZSAg ICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3Rn cmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgDQogICAgICAgICAgICAgIDIxNy4wMCAgMS4zJSBpbnQ4aW5jICAgICAg ICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmlu L3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgDQogICAgICAgICAgICAgIDIxNy4wMCAgMS4zJSBYaWRJbk1W Q0NTbmFwc2hvdCAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5 LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgDQogICAgICAgICAgICAgIDE2OS4wMCAgMS4wJSBf bWRmZF9nZXRzZWcgICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwv cGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgDQpgYGANCkFuZCB3aGVuIHVzZSA2NCBw YXJhbGxlbA0KDQpwb3N0Z3Jlcz0jIGFsdGVyIHRhYmxlIHRfYml0MiBzZXQg KHBhcmFsbGVsX2RlZ3JlZT02NCk7DQpBTFRFUiBUQUJMRQ0KVGltZTogMC4x ODAgbXMNCnBvc3RncmVzPSMgZXhwbGFpbiBzZWxlY3QgY291bnQoKikgZnJv bSB0X2JpdDIgOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUVVFUlkgUExBTiAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogRmluYWxpemUgQWdncmVnYXRl ICAoY29zdD0xMjEwODkyMy45Mi4uMTIxMDg5MjMuOTMgcm93cz0xIHdpZHRo PTgpDQogICAtPiAgR2F0aGVyICAoY29zdD0xMjEwODkxNy4zNS4uMTIxMDg5 MjMuNzYgcm93cz02NCB3aWR0aD04KQ0KICAgICAgICAgV29ya2VycyBQbGFu bmVkOiA2NA0KICAgICAgICAgLT4gIFBhcnRpYWwgQWdncmVnYXRlICAoY29z dD0xMjEwNzkxNy4zNS4uMTIxMDc5MTcuMzYgcm93cz0xCndpZHRoPTgpDQog ICAgICAgICAgICAgICAtPiAgUGFyYWxsZWwgU2VxIFNjYW4gb24gdF9iaXQy ICAoY29zdD0wLjAwLi4xMjA0NjEzMS44OApyb3dzPTI0NzE0MTg4IHdpZHRo PTApDQooNSByb3dzKQ0KDQpUaW1lOiAwLjMzOCBtcw0KcG9zdGdyZXM9IyBz ZWxlY3QgY291bnQoKikgZnJvbSB0X2JpdDIgOw0KICAgY291bnQgICAgDQot LS0tLS0tLS0tLS0NCiAxNjAwMDAwMDAwDQooMSByb3cpDQoNClRpbWU6IDM3 MTgxLjI5NyBtcw0KDQp0aGUgcGVyZnRvcCBpcw0KYGBgDQogICBQZXJmVG9w OiAgIDQ3NjQ5IGlycXMvc2VjICBrZXJuZWw6ODMuNSUgIGV4YWN0OiAgMC4w JSBbMTAwMEh6IGN5Y2xlc10sIAooYWxsLCA2NCBDUFVzKQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KICAgICAgICAgICAgIHNhbXBsZXMgIHBjbnQgZnVuY3Rpb24gICAg ICAgICAgICAgICAgICAgICAgICBEU08NCiAgICAgICAgICAgICBfX19fX19f IF9fX19fIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQogICAgICAgICAgIDQzNjI3MS4wMCA3 Ni41JSBfX211dGV4X2xvY2tfc2xvd3BhdGggICAgICAgICAgIFtrZXJuZWwu a2FsbHN5bXNdCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgIDEzODk3LjAwICAyLjQl IF9zcGluX2xvY2sgICAgICAgICAgICAgICAgICAgICAgW2tlcm5lbC5rYWxs c3ltc10KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICAgMTExNTkuMDAgIDIuMCUgaGVh cF9nZXRuZXh0ICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdz cWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgIDY5MjkuMDAgIDEuMiUgY29weV91c2Vy X2dlbmVyaWNfc3RyaW5nICAgICAgICBba2VybmVsLmthbGxzeW1zXQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgNjQ5Ny4wMCAgMS4xJSBhZHZhbmNlX2FnZ3Jl Z2F0ZXMgICAgICAgICAgICAgCi9ob21lL2RpZ29hbC9wZ3NxbDkuNi9iaW4v cG9zdGdyZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgNTc4Ni4wMCAgMS4wJSBtdXRleF9sb2NrICAgICAgICAg ICAgICAgICAgICAgIFtrZXJuZWwua2FsbHN5bXNdCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICA1MTMzLjAwICAwLjklIG11dGV4X3VubG9jayAgICAgICAgICAg ICAgICAgICAgW2tlcm5lbC5rYWxsc3ltc10KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgIDQ4NjIuMDAgIDAuOSUgRXhlY1Byb2plY3QgICAgICAgICAgICAgICAg ICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIDQz NTEuMDAgIDAuOCUgYWR2YW5jZV90cmFuc2l0aW9uX2Z1bmN0aW9uICAgIAov aG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIDQxMzAuMDAg IDAuNyUgTFdMb2NrQWNxdWlyZSAgICAgICAgICAgICAgICAgIAovaG9tZS9k aWdvYWwvcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIDQxMTkuMDAgIDAuNyUg aGVhcGdldHBhZ2UgICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwv cGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgIDM3NTEuMDAgIDAuNyUgRXhlY1Nj YW4gICAgICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5 LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgIDMyNzUuMDAgIDAuNiUgRXhlY1Byb2NOb2Rl ICAgICAgICAgICAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmlu L3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgIDMxNTkuMDAgIDAuNiUgSGVhcFR1cGxlU2F0aXNmaWVz TVZDQyAgICAgICAgIAovaG9tZS9kaWdvYWwvcGdzcWw5LjYvYmluL3Bvc3Rn cmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgIDMxMjMuMDAgIDAuNSUgbXV0ZXhfc3Bpbl9vbl9vd25lciAgICAg ICAgICAgICBba2VybmVsLmthbGxzeW1zXQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpgYGANCg0Kd2hl biBpIHNldCBwYXJhbGxlIGRlZ3JlZSB0byAxNg0KDQpwb3N0Z3Jlcz0jIGFs dGVyIHRhYmxlIHRfYml0MiBzZXQgKHBhcmFsbGVsX2RlZ3JlZT0xNik7DQpB TFRFUiBUQUJMRQ0KVGltZTogMC40MzMgbXMNCnBvc3RncmVzPSMgc2VsZWN0 IGNvdW50KCopIGZyb20gdF9iaXQyIDsNCiAgIGNvdW50ICAgIA0KLS0tLS0t LS0tLS0tDQogMTYwMDAwMDAwMA0KKDEgcm93KQ0KDQpUaW1lOiA5NTM0LjMw NCBtcw0KDQp0aGUgcGVyZiB0b3AgaXMNCmBgYA0KICAgUGVyZlRvcDogICAx NjQzNiBpcnFzL3NlYyAga2VybmVsOjIxLjklICBleGFjdDogIDAuMCUgWzEw MDBIeiBjeWNsZXNdLCAKKGFsbCwgNjQgQ1BVcykNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQogICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN CiAgICAgICAgICAgICBzYW1wbGVzICBwY250IGZ1bmN0aW9uICAgICAgICAg ICAgICAgICAgICAgICAgRFNPDQogICAgICAgICAgICAgX19fX19fXyBfX19f XyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KICAgICAgICAgICAgMTAwMjAuMDAgMTEuMCUg aGVhcF9nZXRuZXh0ICAgICAgICAgICAgICAgICAgIAovaG9tZS9kZWdlLnp6 ei9wZ3NxbDkuNi9iaW4vcG9zdGdyZXMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgOTgwNC4wMCAxMC44JSBjb3B5 X3VzZXJfZ2VuZXJpY19zdHJpbmcgICAgICAgIFtrZXJuZWwua2FsbHN5bXNd CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICA2MjM5LjAwICA2LjklIGFkdmFuY2Vf YWdncmVnYXRlcyAgICAgICAgICAgICAKL2hvbWUvZGVnZS56enovcGdzcWw5 LjYvYmluL3Bvc3RncmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgIDQ2NjYuMDAgIDUuMSUgRXhlY1Byb2plY3Qg ICAgICAgICAgICAgICAgICAgIAovaG9tZS9kZWdlLnp6ei9wZ3NxbDkuNi9i aW4vcG9zdGdyZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgNDQ5Ni4wMCAgNS4wJSBoZWFwZ2V0cGFnZSAgICAg ICAgICAgICAgICAgICAgCi9ob21lL2RlZ2Uuenp6L3Bnc3FsOS42L2Jpbi9w b3N0Z3JlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICA0NDE5LjAwICA0LjklIEhlYXBUdXBsZVNhdGlzZmllc01W Q0MgICAgICAgICAKL2hvbWUvZGVnZS56enovcGdzcWw5LjYvYmluL3Bvc3Rn cmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgIDM4OTEuMDAgIDQuMyUgRXhlY0NsZWFyVHVwbGUgICAgICAgICAg ICAgICAgIAovaG9tZS9kZWdlLnp6ei9wZ3NxbDkuNi9iaW4vcG9zdGdyZXMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgMzcwMy4wMCAgNC4xJSBFeGVjUHJvY05vZGUgICAgICAgICAgICAgICAg ICAgCi9ob21lL2RlZ2Uuenp6L3Bnc3FsOS42L2Jpbi9wb3N0Z3JlcyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAz NjIwLjAwICA0LjAlIGFkdmFuY2VfdHJhbnNpdGlvbl9mdW5jdGlvbiAgICAK L2hvbWUvZGVnZS56enovcGdzcWw5LjYvYmluL3Bvc3RncmVzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIDMzODUu MDAgIDMuNyUgRXhlY1NjYW4gICAgICAgICAgICAgICAgICAgICAgIAovaG9t ZS9kZWdlLnp6ei9wZ3NxbDkuNi9iaW4vcG9zdGdyZXMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgMjg1NS4wMCAg My4xJSBFeGVjU3RvcmVUdXBsZSAgICAgICAgICAgICAgICAgCi9ob21lL2Rl Z2Uuenp6L3Bnc3FsOS42L2Jpbi9wb3N0Z3JlcyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAyNjQ1LjAwICAyLjkl IFNlcU5leHQgICAgICAgICAgICAgICAgICAgICAgICAKL2hvbWUvZGVnZS56 enovcGdzcWw5LjYvYmluL3Bvc3RncmVzICANCmBgYA0KDQp3aHk/DQoNCmJl c3QgcmVnYXJkcywNCmRpZ29hbAoK
On Wed, May 25, 2016 at 5:21 PM, <digoal@126.com> wrote: > The following bug has been logged on the website: > > Bug reference: 14159 > Logged by: Zhou Digoal > Email address: digoal@126.com > PostgreSQL version: 9.6beta1 > Operating system: CentOS 6.x x64 > Description: > > My test environment: > CentOS 6 > 64 CORE cpu > > this is not use parallel > postgres=# alter table t_bit2 set (parallel_degree=0); > ALTER TABLE > Time: 0.335 ms > > postgres=# select count(*) from t_bit2 ; > count > ------------ > 1600000000 > (1 row) > Time: 141377.100 ms > > and the perftop is > ``` > PerfTop: 1075 irqs/sec kernel:21.5% exact: 0.0% [1000Hz cycles], > (all, 64 CPUs) > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > samples pcnt function DSO > _______ _____ ________________________________ > > _________________________________________________________________________________ > > 2493.00 15.2% heap_getnext > /home/digoal/pgsql9.6/bin/postgres > > > > ``` > And when use 64 parallel > > postgres=# alter table t_bit2 set (parallel_degree=64); > ALTER TABLE > Time: 0.180 ms > postgres=# explain select count(*) from t_bit2 ; > QUERY PLAN > > > ----------------------------------------------------------------------------------------------- > Finalize Aggregate (cost=12108923.92..12108923.93 rows=1 width=8) > -> Gather (cost=12108917.35..12108923.76 rows=64 width=8) > Workers Planned: 64 > -> Partial Aggregate (cost=12107917.35..12107917.36 rows=1 > width=8) > -> Parallel Seq Scan on t_bit2 (cost=0.00..12046131.88 > rows=24714188 width=0) > (5 rows) > > Time: 0.338 ms > postgres=# select count(*) from t_bit2 ; > count > ------------ > 1600000000 > (1 row) > > Time: 37181.297 ms > > the perftop is > ``` > PerfTop: 47649 irqs/sec kernel:83.5% exact: 0.0% [1000Hz cycles], > (all, 64 CPUs) > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > samples pcnt function DSO > _______ _____ _______________________________ > ______________________________________________________________________ > > 436271.00 76.5% __mutex_lock_slowpath > [kernel.kallsyms] > > 13897.00 2.4% _spin_lock > [kernel.kallsyms] > > 11159.00 2.0% heap_getnext > /home/digoal/pgsql9.6/bin/postgres > > > ``` > > when i set paralle degree to 16 > > postgres=# alter table t_bit2 set (parallel_degree=16); > ALTER TABLE > Time: 0.433 ms > postgres=# select count(*) from t_bit2 ; > count > ------------ > 1600000000 > (1 row) > > Time: 9534.304 ms > > the perf top is > ``` > PerfTop: 16436 irqs/sec kernel:21.9% exact: 0.0% [1000Hz cycles], > (all, 64 CPUs) > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > samples pcnt function DSO > _______ _____ _______________________________ > ______________________________________________________________________ > > 10020.00 11.0% heap_getnext > /home/dege.zzz/pgsql9.6/bin/postgres > 9804.00 10.8% copy_user_generic_string > [kernel.kallsyms] > > > ``` > > why? > > Can we get the detailed call stack so that we can know from where the spinlock call is initiated? One guess is that it could be due to the contention on parallel_scan->phs_mutex spinlock which is acquired to move to next heap page, but it is difficult to say from the information provided. In general, I think using more than required workers can lead to slow down in system and this seems to be one example of same. By the way, what is the value selected by system for parallel workers if you don't set parallel_degree parameter for a relation, you can check that by setting default value (-1) of parallel_degree for a relation and max_parallel_degree = 64 and max_worker_processes = 64. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On Thu, May 26, 2016 at 11:03 AM, =E5=BE=B7=E5=93=A5 <digoal@126.com> wrote= : > This is worker process's stack, when i test the hign parallel degree. > > [<ffffffffa00b8ff0>] ext4_llseek+0x60/0x110 [ext4] > [<ffffffff81186eda>] vfs_llseek+0x3a/0x40 > [<ffffffff81188b96>] sys_lseek+0x66/0x80 > [<ffffffff8100c072>] system_call_fastpath+0x16/0x1b > [<ffffffffffffffff>] 0xffffffffffffffff > > Above call stack indicates that the file seek cost has increased on employing high number of workers. I think the reason is that employing more number of workers to perform parallel scan of same file doesn't work very well read-ahead mechanism of OS. I think the best gain is possible only when we use parallel degree which is most appropriate for the work load, so unless you are sure that higher number of workers are required for your workload, use system's default behaviour which is to set the max_parallel_degree and let system decide how many workers are required. Right now, we don't have very sophisticated way of defining how many workers are appropriate for any workload, but I think it will work better than directly setting parallel degree for a relation to very high number. Note - Always keep the appropriate pg mailing list in cc for communication which in this case is pgsql-bugs@postgresql.org. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On 2016-05-27 05:43:00 +0530, Amit Kapila wrote: > On Thu, May 26, 2016 at 11:03 AM, å¾·å¥ <digoal@126.com> wrote: > > > This is worker process's stack, when i test the hign parallel degree. > > > > [<ffffffffa00b8ff0>] ext4_llseek+0x60/0x110 [ext4] > > [<ffffffff81186eda>] vfs_llseek+0x3a/0x40 > > [<ffffffff81188b96>] sys_lseek+0x66/0x80 > > [<ffffffff8100c072>] system_call_fastpath+0x16/0x1b > > [<ffffffffffffffff>] 0xffffffffffffffff > > > > > > Above call stack indicates that the file seek cost has increased on > employing high number of workers. I think the reason is that employing > more number of workers to perform parallel scan of same file doesn't work > very well read-ahead mechanism of OS. I don't think that's the correct conclusion. That report and profiles rather seems to suggest we're hitting lock contention, rather than IO related cost. The kernel used here is quite old (heavily patched 2.6.32 IIRC). The kernel guys have since made lseek not take locks in the common case. I suspect that upgrading to a newer kernel will change the profile significantly. Greetings, Andres Freund
On Fri, May 27, 2016 at 5:51 AM, Andres Freund <andres@anarazel.de> wrote: > > On 2016-05-27 05:43:00 +0530, Amit Kapila wrote: > > On Thu, May 26, 2016 at 11:03 AM, =E5=BE=B7=E5=93=A5 <digoal@126.com> w= rote: > > > > > This is worker process's stack, when i test the hign parallel degree. > > > > > > [<ffffffffa00b8ff0>] ext4_llseek+0x60/0x110 [ext4] > > > [<ffffffff81186eda>] vfs_llseek+0x3a/0x40 > > > [<ffffffff81188b96>] sys_lseek+0x66/0x80 > > > [<ffffffff8100c072>] system_call_fastpath+0x16/0x1b > > > [<ffffffffffffffff>] 0xffffffffffffffff > > > > > > > > > > Above call stack indicates that the file seek cost has increased on > > employing high number of workers. I think the reason is that employing > > more number of workers to perform parallel scan of same file doesn't work > > very well read-ahead mechanism of OS. > > I don't think that's the correct conclusion. That report and profiles > rather seems to suggest we're hitting lock contention, rather than IO > related cost. > > The kernel used here is quite old (heavily patched 2.6.32 IIRC). The > kernel guys have since made lseek not take locks in the common case. I > suspect that upgrading to a newer kernel will change the profile > significantly. > Worth trying, however I don't think we can discount the fact that using such large number of workers can saturate I/O channel. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On 2016-05-27 11:27:59 +0530, Amit Kapila wrote: > On Fri, May 27, 2016 at 5:51 AM, Andres Freund <andres@anarazel.de> wrote: > > > > On 2016-05-27 05:43:00 +0530, Amit Kapila wrote: > > > On Thu, May 26, 2016 at 11:03 AM, å¾·å¥ <digoal@126.com> wrote: > > > > > > > This is worker process's stack, when i test the hign parallel degree. > > > > > > > > [<ffffffffa00b8ff0>] ext4_llseek+0x60/0x110 [ext4] > > > > [<ffffffff81186eda>] vfs_llseek+0x3a/0x40 > > > > [<ffffffff81188b96>] sys_lseek+0x66/0x80 > > > > [<ffffffff8100c072>] system_call_fastpath+0x16/0x1b > > > > [<ffffffffffffffff>] 0xffffffffffffffff > > > > > > > > > > > > > > Above call stack indicates that the file seek cost has increased on > > > employing high number of workers. I think the reason is that employing > > > more number of workers to perform parallel scan of same file doesn't > work > > > very well read-ahead mechanism of OS. > > > > I don't think that's the correct conclusion. That report and profiles > > rather seems to suggest we're hitting lock contention, rather than IO > > related cost. > > > > The kernel used here is quite old (heavily patched 2.6.32 IIRC). The > > kernel guys have since made lseek not take locks in the common case. I > > suspect that upgrading to a newer kernel will change the profile > > significantly. > > > > Worth trying, however I don't think we can discount the fact that using > such large number of workers can saturate I/O channel. Sure, that can be an issue. But if it were the bottleneck we wouldn't see contention in a kernel spinlock, below lseek() (which in a postgres workload pretty much never has to do IO). Greetings, Andres Freund