| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Lars Aksel Opsahl <Lars(dot)Opsahl(at)nibio(dot)no> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: SubtransControlLock and performance problems |
| Date: | 2020-02-19 15:23:53 |
| Message-ID: | 20200219152353.GA2663@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 2020-Feb-19, Lars Aksel Opsahl wrote:
> With the values above I did see same performance problems and we ended
> with a lot of subtransControlLock.
>
> So I started to change the code based on your feedbacks.
>
> - What seems to work very good in combination with a catch exception
> and retry pattern is to insert the data in to separate table for each
> job. (I the current testcase we reduced the number of
> subtransControlLock from many hundreds to almost none.)
I think at this point your only recourse is to start taking profiles to
see where the time is going. Without that, you're just flying blind and
whatever you do will not necessarily move your needle at all.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-02-20 04:35:03 | Re: How to avoid UPDATE performance degradation in a transaction |
| Previous Message | Justin Pryzby | 2020-02-19 13:08:38 | Re: tablespace to benefit from ssd ? |