From: | azhwkd <azhwkd(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: query locks up when run concurrently |
Date: | 2016-11-23 21:52:04 |
Message-ID: | CAJ_VqiwM=gHw4MO-zy5RbqVWmGT9zU+iJPW9phzWVst90ffc=A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings!
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(at)sss(dot)pgh(dot)pa(dot)us> schrieb am Mi., 23. Nov. 2016 um 17:47 Uhr:
> azhwkd(at)gmail(dot)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?
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | greigwise | 2016-11-23 21:56:50 | Query with large in clauses uses a lot of memory |
Previous Message | azhwkd | 2016-11-23 21:47:09 | Re: query locks up when run concurrently |