Re: xmin and very high number of concurrent transactions
От | Julien Rouhaud |
---|---|
Тема | Re: xmin and very high number of concurrent transactions |
Дата | |
Msg-id | CAOBaU_afvF-SzYFgfvf9bX60yk6A2XuZd3ZvfW7KV3XZcdHLmg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: xmin and very high number of concurrent transactions (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: [External] Re: xmin and very high number of concurrent transactions
|
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: