From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Vijaykumar Jain <vjain(at)opentable(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: xmin and very high number of concurrent transactions |
Date: | 2019-03-13 09:14:01 |
Message-ID: | CAOBaU_afvF-SzYFgfvf9bX60yk6A2XuZd3ZvfW7KV3XZcdHLmg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Mar 13, 2019 at 9:50 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> Vijaykumar Jain wrote:
> > I was asked this question in one of my demos, and it was interesting one.
> >
> > we update xmin for new inserts with the current txid.
> > now in a very high concurrent scenario where there are more than 2000
> > concurrent users trying to insert new data,
> > will updating xmin value be a bottleneck?
> >
> > i know we should use pooling solutions to reduce concurrent
> > connections but given we have enough resources to take care of
> > spawning a new process for a new connection,
>
> You can read the function GetNewTransactionId in
> src/backend/access/transam/varsup.c for details.
>
> Transaction ID creation is serialized with a "light-weight lock",
> so it could potentially be a bottleneck.
Also I think that GetSnapshotData() would be the major bottleneck way
before GetNewTransactionId() becomes problematic. Especially with
such a high number of active backends.
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Otterbach | 2019-03-13 11:24:00 | PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (actually out of memory with PG11) |
Previous Message | Laurenz Albe | 2019-03-13 08:49:40 | Re: xmin and very high number of concurrent transactions |