Re: advance local xmin more aggressively - Mailing list pgsql-hackers

From Robert Haas
Subject Re: advance local xmin more aggressively
Date
Msg-id CA+TgmoZDZoj48v=BRQCx0=KAJ8mEgf7swoccE7fZH5n+3ySLTg@mail.gmail.com
Whole thread Raw
In response to Re: advance local xmin more aggressively  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: advance local xmin more aggressively  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
>> Care to code it up?
>
> Here you are.

That was quick.

You need to add a semicolon to the end of line 20 in pairingheap.c.

I wonder what the worst case for this is.  I tried it on your
destruction test case from before and it doesn't seem to cost anything
material:

your patch: 0m38.714s 0m34.424s 0m35.191s
master: 0m35.260s 0m34.643s 0m34.945s
my patch: 0m34.728s 0m34.619s 0m35.015s

The first measurement with your patch is somewhat of an outlier, but
that was also the first measurement I took, which might have thrown
off the results.  Basically, either your patch or my patch looks free
from here.  I'm kind of suspicious about that: it doesn't seem like
the additional linked-list manipulation you're doing in
RegisterSnapshotOnOwner ought to cost something, but maybe that
function just isn't called enough for it to matter, at least on this
test case.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Casting issues with domains
Next
From: Tom Lane
Date:
Subject: Re: thinko in convertToJsonb()