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

Re: testing HS/SR - 1 vs 2 performance

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: testing HS/SR - 1 vs 2 performance
Date: 2010-04-17 20:14:33
Message-ID: 1271535273.8305.12088.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, 2010-04-17 at 15:45 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Sat, 2010-04-17 at 11:13 -0400, Tom Lane wrote:
> >> It'd be cheaper anyway to sort and search the
> >> array using plain <, so why are you so eager to use
> >> TransactionIdFollows?
> > The array grows to the right and is laid out one xid per element,
> > resulting in a sequence of values that are transactionid-monotonic.
> How do you know that just adding items at the right will produce a
> sorted array?  It seems quite unlikely to me that transactions can be
> guaranteed to arrive at this code in XID order.  I think you need to do
> an explicitly sorted insertion.

Xids don't arrive in sequence, but "known assigned xids" are added in
sequence because we infer the existence of the intermediate xids and
assuming they are running for the snapshot.

> > ... Doing it this way means that we can
> > add rows past the head of the array and then move the head atomically,
> > so that we can make adding xids lock-free.
> ... and even without that issue, this seems like utter fantasy.  How
> are you going to do that "atomically"?  Have you considered what will
> happen on weak-memory-ordering machines like PPC, in particular?

We search the array between tail and head. If the head moves by integer
overwrite just as already happens for xid assignment, then we would use
the new head for the search. The code is careful to fetch only once.

I would freely admit I know absolutely nothing about details of
weak-memory-ordering machines and have not considered them at all. How
would what I have proposed fail to work, yet what we already rely on
work correctly? Do the circumstances differ?

 Simon Riggs 

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-04-17 20:48:21
Subject: Re: testing HS/SR - 1 vs 2 performance
Previous:From: Tom LaneDate: 2010-04-17 19:45:47
Subject: Re: testing HS/SR - 1 vs 2 performance

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