Re: Proposal for CSN based snapshots - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Proposal for CSN based snapshots
Date
Msg-id 53FD7D65.9040602@vmware.com
Whole thread Raw
In response to Re: Proposal for CSN based snapshots  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Proposal for CSN based snapshots
List pgsql-hackers
On 08/27/2014 08:23 AM, Jeff Davis wrote:
> On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote:
>> Yeah. This patch in the current state is likely much much slower than
>> unpatched master, except in extreme cases where you have thousands of
>> connections and short transactions so that without the patch, you spend
>> most of the time acquiring snapshots.
>
> What else are you looking to accomplish with this patch during this
> 'fest? Bug finding? Design review? Performance testing?

Design review, mostly. I know the performance still sucks. Although if 
you can foresee some performance problems, aside from the extra CSNLOG 
lookups, it would be good to know.

> I think there's already at least one design issue to consider, which is
> whether we care about CLOG/CSNLOG access for hinted records where the
> xid > snapshot->xmin (that is, accesses that previously would have
> looked at xip). Would more discussion help here or do we need to wait
> for performance numbers?

I think my current plan is to try to make that CSNLOG lookup fast. In 
essence, rewrite SLRUs to be more performant. That would help with the 
current clog, too, which would make it more feasible to set hint bits 
less often. In particular, avoid dirtying pages just to set hint bits. 
I'm not sure if that's enough - you can't beat checking a single hint 
bit in the same cache line as the XID - but I think it's worth a try.

- Heikki




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Next
From: Andres Freund
Date:
Subject: Re: REINDEX CONCURRENTLY 2.0