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.klaver@xxxxxxxxxxx> 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.klaver@xxxxxxxxxxx
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
