[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: Doubt in mvcc
From: Naresh gandi <naresh5310 () gmail ! com>
Date: 2020-07-30 8:39:58
Message-ID: CABXEXoPxiPoZUGdDfXP6LCgCxt8z9OhUYHxukdicRmzCsk4Mcw () mail ! gmail ! com
[Download RAW message or body]
Dear Ramakrishna,
"two different transactions can update the same version of the row"
This answer itself is wrong.
In my point of view, the drawback of MVCC is just holding multiple versions
of tuple in a table which leads to slowness in application access. the more
your table is bloated the more it takes to retrieve data.it has to scan so
much of _VM, so many pages which is time consuming.
The other drawback is anyway space.
There are a couple of workarounds to address the issue is what you should
tell your recruiter.
Any RDBMS has its own mechanism to address Isolation property and each
mechanism has it own flaws.
On Thu, Jul 23, 2020 at 12:16 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, Jul 13, 2020 at 10:41:28AM +0200, Francisco Olarte wrote:
> > Rama:
> >
> > On Mon, Jul 13, 2020 at 9:52 AM Rama Krishnan <raghuldrag@gmail.com>
> wrote:
> > > I m preparing for interview one of the recruiter asked me mvcc
> drawbacks as i told due to mvcc it use more space and need to perform
> maintenance activity.
> > > Another one is the same data causes an update conflict because two
> different transactions can update the same version of the row.
> > > he told its wrong, kindly tell me will you please tell me its correct
> or wrong?
> >
> > I'm not sure I understand your question too well, you may want to
> > refresh/expand.
> >
> > One interpretation is, on a pure MVCC contest, two transactions, say 5
> > and 6, could try to update a tuple valid for [1,) and end up
> > generating two new tuples, [5,), [6,) and closing the original at
> > either [1,5) or [1,6) .
> >
> > That's why MVCC is just a piece, locking is other. On a MVCC the
> > tuples are locked while a transaction manipulates them. Other
> > transactions may read them, which is why readers do not block writers,
> > but two updates on the same tuple serialize.
>
> You might want to look at this:
>
> https://momjian.us/main/presentations/internals.html#mvcc
>
> --
> Bruce Momjian <bruce@momjian.us> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> The usefulness of a cup is in its emptiness, Bruce Lee
>
>
>
>
[Attachment #3 (text/html)]
<div dir="ltr">Dear Ramakrishna,<div><br></div><div><span \
style="color:rgb(73,73,73);font-family:"open \
sans",sans-serif;font-size:19px">"two different transactions can update the \
same version of the row"</span><br></div><div><span \
style="color:rgb(73,73,73);font-family:"open \
sans",sans-serif;font-size:19px"><br></span></div><div><span \
style="color:rgb(73,73,73);font-family:"open \
sans",sans-serif;font-size:19px">This answer itself is \
wrong.</span></div><div><span style="color:rgb(73,73,73);font-family:"open \
sans",sans-serif;font-size:19px"><br></span></div><div><font color="#494949" \
face="open sans, sans-serif"><span style="font-size:19px">In my point of view, the \
drawback of MVCC is just holding multiple versions of tuple in a table which leads to \
slowness in application access. the more your table is bloated the more it takes to \
retrieve <a href="http://data.it">data.it</a> has to scan so much of _VM, so many \
pages which is time consuming.</span></font></div><div><font color="#494949" \
face="open sans, sans-serif"><span \
style="font-size:19px"><br></span></font></div><div><font color="#494949" face="open \
sans, sans-serif"><span style="font-size:19px">The other drawback is anyway \
space.</span></font></div><div><font color="#494949" face="open sans, \
sans-serif"><span style="font-size:19px"><br></span></font></div><div><font \
color="#494949" face="open sans, sans-serif"><span style="font-size:19px">There are a \
couple of workarounds to address the issue is what you should tell your \
recruiter.</span></font></div><div><font color="#494949" face="open sans, \
sans-serif"><span style="font-size:19px"><br></span></font></div><div><font \
color="#494949" face="open sans, sans-serif"><span style="font-size:19px">Any RDBMS \
has its own mechanism to address Isolation property and each mechanism has it own \
flaws. </span></font></div><div><span \
style="color:rgb(73,73,73);font-family:"open \
sans",sans-serif;font-size:19px"><br></span></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 23, 2020 at 12:16 \
AM Bruce Momjian <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jul 13, 2020 \
at 10:41:28AM +0200, Francisco Olarte wrote:<br> > Rama:<br>
> <br>
> On Mon, Jul 13, 2020 at 9:52 AM Rama Krishnan <<a \
href="mailto:raghuldrag@gmail.com" target="_blank">raghuldrag@gmail.com</a>> \
wrote:<br> > > I m preparing for interview one of the recruiter asked me mvcc \
drawbacks as i told due to mvcc it use more space and need to perform maintenance \
activity.<br> > > Another one is the same data causes an update conflict \
because two different transactions can update the same version of the row.<br> > \
> he told its wrong, kindly tell me will you please tell me its correct or \
wrong?<br> > <br>
> I'm not sure I understand your question too well, you may want to<br>
> refresh/expand.<br>
> <br>
> One interpretation is, on a pure MVCC contest, two transactions, say 5<br>
> and 6, could try to update a tuple valid for [1,) and end up<br>
> generating two new tuples, [5,), [6,) and closing the original at<br>
> either [1,5) or [1,6) .<br>
> <br>
> That's why MVCC is just a piece, locking is other. On a MVCC the<br>
> tuples are locked while a transaction manipulates them. Other<br>
> transactions may read them, which is why readers do not block writers,<br>
> but two updates on the same tuple serialize.<br>
<br>
You might want to look at this:<br>
<br>
<a href="https://momjian.us/main/presentations/internals.html#mvcc" \
rel="noreferrer" target="_blank">https://momjian.us/main/presentations/internals.html#mvcc</a><br>
<br>
-- <br>
Bruce Momjian <<a href="mailto:bruce@momjian.us" \
target="_blank">bruce@momjian.us</a>> <a href="https://momjian.us" \
rel="noreferrer" target="_blank">https://momjian.us</a><br> EnterpriseDB \
<a href="https://enterprisedb.com" rel="noreferrer" \
target="_blank">https://enterprisedb.com</a><br> <br>
The usefulness of a cup is in its emptiness, Bruce Lee<br>
<br>
<br>
<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic