Re: cheaper snapshots redux - Mailing list pgsql-hackers

>If you know what transactions were running the last time a snapshot summary was written and what >transactions have ended since then, you can work out the new xmin on the fly.  I have working >code for this and it's actually quite simple.

I believe one method to do same is as follows:

Let us assume at some point of time the snapshot and completed XID list is somewhat as follows:

Snapshot

{

Xmin – 5

Xip[] – 8 10 12

Xmax  - 15

}

Committed XIDS – 8, 10 , 12, 18, 20, 21

So it means 16,17,19 are running transactions. So it will behave as follows:

Xmin – 16

Xmax – 21

Xip[] – 17,19

But if we do above way to calculate Xmin, we need to check in existing Xip array and committed Xid array to find Xmin. Won’t this cause reasonable time even though it is outside lock time if Xip and Xid are large.

> Because GetSnapshotData() computes a new value for RecentGlobalXmin by scanning the ProcArray.  > This isn't costing a whole lot extra right now because the xmin and xid fields are normally in > the same cache line, so once you've looked at one of them it doesn't cost that much extra to

> look at the other.  If, on the other hand, you're not looking at (or even locking) the

> ProcArray, then doing so just to recomputed RecentGlobalXmin sucks.

Yes, this is more time as compare to earlier, but if our approach to calculate Xmin is like above point, then one extra read outside lock should not matter. However if for above point approach is different then it will be costlier.

***************************************************************************************

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!

-----Original Message-----
From: Robert Haas [mailto:robertmhaas@gmail.com]
Sent: Monday, September 12, 2011 7:39 PM
To: Amit Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] cheaper snapshots redux

On Sun, Sep 11, 2011 at 11:08 PM, Amit Kapila <amit.kapila@huawei.com> wrote:

>   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 as snapshot will

> not be updated everytime so xmin cannot be latest always.

If you know what transactions were running the last time a snapshot

summary was written and what transactions have ended since then, you

can work out the new xmin on the fly.  I have working code for this

and it's actually quite simple.

>>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.

Because GetSnapshotData() computes a new value for RecentGlobalXmin by

scanning the ProcArray.  This isn't costing a whole lot extra right

now because the xmin and xid fields are normally in the same cache

line, so once you've looked at one of them it doesn't cost that much

extra to look at the other.  If, on the other hand, you're not looking

at (or even locking) the ProcArray, then doing so just to recompute

RecentGlobalXmin sucks.

--

Robert Haas

EnterpriseDB: http://www.enterprisedb.com

The Enterprise PostgreSQL Company