From: | Vijaykumar Jain <vjain(at)opentable(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: [External] Re: xmin and very high number of concurrent transactions |
Date: | 2019-03-13 18:35:02 |
Message-ID: | CAE7uO5irVhgFoabRYEUz-YAASSHp4xHWEr+E_SVum2m_+UOwog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com> wrote:
> 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.
>
--
Regards,
Vijay
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2019-03-13 19:23:31 | Re: Autovacuum Transaction Wraparound |
Previous Message | Michel Pelletier | 2019-03-13 17:39:37 | varlena objects greater than 1GB |