From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | Юрий Соколов <funny(dot)falcon(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres stucks in deadlock detection |
Date: | 2018-04-20 15:36:58 |
Message-ID: | CA+Tgmob=Ov0=UJNLfnPOadNHGUsGkPv_sbYsycn96EpcoLr9Kw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 18, 2018 at 10:08 AM, Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
> And it is very hard not to notice 17-times difference.
> Certainly it is true in the assumption that most deadlock timeout expiration
> are caused by high workload and contention, and not by real deadlocks.
> But it seems to be quite common case.
If I understand this workload correctly, the contention is for the
relation extension lock. But I think we're likely to move that out of
the heavyweight lock manager altogether in the not-too-distant future,
as proposed in https://commitfest.postgresql.org/17/1133/ ? I'd be
interested in hearing what happens to performance with that patch
applied.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-04-20 15:58:50 | Re: [HACKERS] path toward faster partition pruning |
Previous Message | Robert Haas | 2018-04-20 15:32:07 | Re: [HACKERS] proposal: schema variables |