Re: [External] Re: xmin and very high number of concurrent transactions - Mailing list pgsql-general

From Vijaykumar Jain
Subject Re: [External] Re: xmin and very high number of concurrent transactions
Date
Msg-id CAE7uO5irVhgFoabRYEUz-YAASSHp4xHWEr+E_SVum2m_+UOwog@mail.gmail.com
Whole thread Raw
In response to Re: xmin and very high number of concurrent transactions  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-general
Thank you everyone for responding.
Appreciate your help.

Looks like I need to understand the concepts a little more in detail , to be able to ask the right questions, but atleast now I can look at  the relevant docs.


On Wed, 13 Mar 2019 at 2:44 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
On Wed, Mar 13, 2019 at 9:50 AM Laurenz Albe <laurenz.albe@cybertec.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.
--

Regards,
Vijay

pgsql-general by date:

Previous
From: Michel Pelletier
Date:
Subject: varlena objects greater than 1GB
Next
From: Adrian Klaver
Date:
Subject: Re: Autovacuum Transaction Wraparound