>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:robertmh...@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.kap...@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
