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

From Laurenz Albe
Subject Re: xmin and very high number of concurrent transactions
Date
Msg-id a7a3fc9d64b2884e2108e39189ec1aa943097b1b.camel@cybertec.at
Whole thread Raw
In response to xmin and very high number of concurrent transactions  (Vijaykumar Jain <vjain@opentable.com>)
Responses Re: xmin and very high number of concurrent transactions  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-general
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.

Often that is dwarfed by the I/O requirements from many concurrent
commits, but if most of your transactions are rolled back or you
use "synchronous_commit = off", I can imagine that it could matter.

It is not a matter of how many clients there are, but of how
often a new writing transaction is started.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com



pgsql-general by date:

Previous
From: Jahwan Kim
Date:
Subject: PostgreSQL temp table blues
Next
From: Julien Rouhaud
Date:
Subject: Re: xmin and very high number of concurrent transactions