Skip site navigation (1) Skip section navigation (2)

Re: cheaper snapshots redux

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cheaper snapshots redux
Date: 2011-09-10 12:04:36
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C380B722FFF@szxeml509-mbx.china.huawei.com (view raw or flat)
Thread:
Lists: pgsql-hackers
>> 4. Won't it effect if we don't update xmin everytime and just noting the committed XIDs. The reason I am asking is that it is used in tuple visibility check so with new idea in some cases instead of just returning >>     from begining by checking xmin it has to go through the committed XID list.

>> I understand that there may be less cases or the improvement by your idea can supesede this minimal effect. However some cases can be defeated.

>The snapshot xmin has to be up to date.  I'm not planning to break that because it would be wrong.

   In the approach mentioned in your idea, it mentioned that once after taking snapshot, only committed XIDs will be updated and sometimes snapshot itself.

   So when the xmin will be updated according to your idea.

>RecentGlobalXmin doesn't need to be completely up to date, and in fact recomputing it on every snapshot becomes prohibitively expensive with this approach.  I'm still struggling with the best way to handle that.

   RecentGlobalXmin and RecentXmin are mostly updated with snapshots xmin and that too outside ProcArrayLock, so why it will be expensive if you have updated xmin.


With Regards,

Amit Kapila.

***************************************************************************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

pgsql-hackers by date

Next:From: Thom BrownDate: 2011-09-10 12:13:51
Subject: Re: 9.1rc1 bug: extension types not dropped with DROP SCHEMA CASCADE
Previous:From: Marti RaudseppDate: 2011-09-10 11:46:59
Subject: 9.1rc1 bug: extension types not dropped with DROP SCHEMA CASCADE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group