The parallel calls should not be working on the same row. Each query services a different group ID on it's own and there is no overlap.
Kind regards,
Sebastian
Tom Lane <tgl@sss.pgh.pa.us> schrieb am Mi., 23. Nov. 2016 um 17:47 Uhr:
azhwkd@gmail.com writes: > I have a query which if run alone usually completes in about 300ms. > When run in my application this query constantly locks up and bogs > down all connections of the connection pool (In the application this > query is run up to 10 times in parallel with different parameters). > What's really weird is that I can re-run one of the hung queries from > the command line while it's hung and it will complete as expected > while the hung queries continue to use 100% CPU time.
Judging from the EXPLAIN timing, most of the work is in the trigger, which leads me to wonder if the parallel calls are likely to be fighting over inserting/updating the same row in the group_history partition tables. Or are you certain that they should be hitting different rows?