Simon Riggs writes:
> On 25 August 2015 at 21:51, Tom Lane wrote:
>> I don't mean to dismiss the potential for further optimization inside
>> XidInMVCCSnapshot (for instance, the one-XID-cache idea sounds promising);
>> but I think that's material for further research and a separate patch.
> Pat
On 25 August 2015 at 21:51, Tom Lane wrote:
>
> I don't mean to dismiss the potential for further optimization inside
> XidInMVCCSnapshot (for instance, the one-XID-cache idea sounds promising);
> but I think that's material for further research and a separate patch.
>
Patch attached. Doesn't se
On Wed, Aug 26, 2015 at 2:21 AM, Tom Lane wrote:
>
> Amit Kapila writes:
>
> > I am wondering that is there any harm in calling TransactionIdDidAbort()
> > in slow path before calling SubTransGetTopmostTransaction(), that can
> > also maintain consistency of checks in both the functions?
>
> I th
Tom Lane wrote:
> Amit Kapila writes:
> > I am wondering that is there any harm in calling TransactionIdDidAbort()
> > in slow path before calling SubTransGetTopmostTransaction(), that can
> > also maintain consistency of checks in both the functions?
>
> I think this is probably a bad idea. It
Amit Kapila writes:
> On Fri, Aug 21, 2015 at 8:22 PM, Robert Haas wrote:
>> On Wed, Aug 19, 2015 at 2:53 AM, Amit Kapila
>>> Another minor point is, I think we should modify function level comment
>>> for XidInMVCCSnapshot() where it says that this applies to known-
>>> committed XIDs which wil
On Fri, Aug 21, 2015 at 8:22 PM, Robert Haas wrote:
>
> On Wed, Aug 19, 2015 at 2:53 AM, Amit Kapila
wrote:
> > I think one case where the patch can impact is for aborted transactions.
> > In TransactionIdIsInProgress(), we check for aborted transactions before
> > consulting pg_subtrans whereas
Robert Haas writes:
> On Tue, Aug 18, 2015 at 8:36 PM, Tom Lane wrote:
>> I experimented with the attached patch, which replaces
>> HeapTupleSatisfiesMVCC's calls of TransactionIdIsInProgress with
>> XidInMVCCSnapshot, and then as a cross-check has all the "return false"
>> exits from XidInMVCCSn
On Wed, Aug 19, 2015 at 2:53 AM, Amit Kapila wrote:
> I think one case where the patch can impact is for aborted transactions.
> In TransactionIdIsInProgress(), we check for aborted transactions before
> consulting pg_subtrans whereas with patch it will consult pg_subtrans
> without aborted transa
On Tue, Aug 18, 2015 at 8:36 PM, Tom Lane wrote:
> I wrote:
>> Just thinking about this ... I wonder why we need to call
>> TransactionIdIsInProgress() at all rather than believing the answer from
>> the snapshot? Under what circumstances could TransactionIdIsInProgress()
>> return true where Xid
On Tue, Aug 18, 2015 at 5:36 PM, Tom Lane wrote:
> I wrote:
> > Just thinking about this ... I wonder why we need to call
> > TransactionIdIsInProgress() at all rather than believing the answer from
> > the snapshot? Under what circumstances could TransactionIdIsInProgress()
> > return true wher
On 19 August 2015 at 16:21, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> I'm not sure about it, but it might be worthwhile to add a
> >> TransactionIdIsKnownCompleted() check before the more expensive parts of
> >> XidInMVCCSnapshot(). Neither the array search nor, much more so, the
I wrote:
> Andres Freund writes:
>> I'm not sure about it, but it might be worthwhile to add a
>> TransactionIdIsKnownCompleted() check before the more expensive parts of
>> XidInMVCCSnapshot(). Neither the array search nor, much more so, the
>> subtrans lookups are free.
> Hmmm... the comment fo
On 2015-08-19 10:55:00 -0400, Tom Lane wrote:
> My own thought about reducing the cost of XidInMVCCSnapshot, if that
> proves necessary, is that maybe it would be worth the trouble to sort
> the arrays so we could use binary search. That would increase the
> cost of snapshot acquisition noticeably
Andres Freund writes:
> On 2015-08-18 20:36:13 -0400, Tom Lane wrote:
>> I experimented with the attached patch, which replaces
>> HeapTupleSatisfiesMVCC's calls of TransactionIdIsInProgress with
>> XidInMVCCSnapshot, and then as a cross-check has all the "return false"
>> exits from XidInMVCCSnap
On 19 August 2015 at 15:08, Andres Freund wrote:
> On 2015-08-18 20:36:13 -0400, Tom Lane wrote:
> > I wrote:
> > > Just thinking about this ... I wonder why we need to call
> > > TransactionIdIsInProgress() at all rather than believing the answer
> from
> > > the snapshot? Under what circumstan
On 2015-08-18 20:36:13 -0400, Tom Lane wrote:
> I wrote:
> > Just thinking about this ... I wonder why we need to call
> > TransactionIdIsInProgress() at all rather than believing the answer from
> > the snapshot? Under what circumstances could TransactionIdIsInProgress()
> > return true where Xid
On 19 August 2015 at 00:49, Tom Lane wrote:
> Jeff Janes writes:
> > When we check a tuple for MVCC, it has to pass checks that the inserting
> > transaction has committed, and that it committed before our snapshot
> > began. And similarly that the deleting transaction hasn't committed, or
> >
On Wed, Aug 19, 2015 at 6:06 AM, Tom Lane wrote:
>
> I wrote:
> > Just thinking about this ... I wonder why we need to call
> > TransactionIdIsInProgress() at all rather than believing the answer from
> > the snapshot? Under what circumstances could
TransactionIdIsInProgress()
> > return true whe
I wrote:
> Just thinking about this ... I wonder why we need to call
> TransactionIdIsInProgress() at all rather than believing the answer from
> the snapshot? Under what circumstances could TransactionIdIsInProgress()
> return true where XidInMVCCSnapshot() had not?
I experimented with the attac
Jeff Janes writes:
> When we check a tuple for MVCC, it has to pass checks that the inserting
> transaction has committed, and that it committed before our snapshot
> began. And similarly that the deleting transaction hasn't committed, or
> did so after our snapshot.
> XidInMVCCSnapshot is (or c
When we check a tuple for MVCC, it has to pass checks that the inserting
transaction has committed, and that it committed before our snapshot
began. And similarly that the deleting transaction hasn't committed, or
did so after our snapshot.
XidInMVCCSnapshot is (or can be) very much cheaper
than
21 matches
Mail list logo
