Re: [External] Re: xmin and very high number of concurrent transactions

On 3/12/19 1:02 PM, Vijaykumar Jain wrote:
> no i mean not we end users, postgres does it (?) via the xmin and xmax
> fields from inherited tables :) if that is what you wanted in a why
> or are you asking, does postgres even update those rows and i am wrong
> assuming it that way?

Not sure where the inherited tables come in?

See below for more info:
https://www.postgresql.org/docs/11/storage-page-layout.html

AFAIK xmin and xmax are just done as part of the insert or delete
operations so there is no updating involved.

I would say the impact to performance would come from the overhead of
each connection rather then maintaining xmin/xmax.

>
> since the values need to be atomic,
> consider the below analogy
> assuming i(postgres) am person giving out token to
> people(connections/tx) in a queue.
> if there is a single line, (sequential) then it is easy for me to
> simply give them 1 token incrementing the value and so on.
> but if there are thousands of users in parallel lines, i am only one
> person delivering the token, will operate sequentially, and the other
> person is "blocked" for sometime before it gets the token with the
> required value.
> so if there are 1000s or users with the "delay" may impact my
> performance coz i need to maintain the value of the token to be able
> to know what token value i need to give to next person?
>
> i do not know if am explaining it correctly, pardon my analogy,
>
>
> Regards,
> Vijay
>
> On Wed, Mar 13, 2019 at 1:10 AM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>>
>> On 3/12/19 12:19 PM, 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.
>>
>> Why?
>>
>>> 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,
>>>
>>> Regards,
>>> Vijay
>>>
>>>
>>
>>
>> --
>> Adrian Klaver
>> adrian(dot)klaver(at)aklaver(dot)com

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com