From: Markus Wanner <markus@bluegap.ch>
To: Ants Aasma <ants@cybertec.at>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Proposal for CSN based snapshots
Date: Tue, 11 Jun 2013 08:53:47 +0200
Message-ID: <51B6C97B.1070000@bluegap.ch> (raw)
In-Reply-To: <CA+CSw_uSzXidemci-nU5fJY-qXD0DE0ZWz-j1ASTT_ffBjXo9Q@mail.gmail.com>
References: <CA+CSw_tEpJ=md1zgxPkjH6CWDnTDft4gBi=+P9SnoC+Wy3pKdA@mail.gmail.com>
<51B1CB35.4050406@bluegap.ch>
<CA+CSw_uSzXidemci-nU5fJY-qXD0DE0ZWz-j1ASTT_ffBjXo9Q@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Ants,
the more I think about this, the more I start to like it.
On 06/07/2013 02:50 PM, Ants Aasma wrote:
> On Fri, Jun 7, 2013 at 2:59 PM, Markus Wanner <markus@bluegap.ch> wrote:
>> Agreed. Postgres-R uses a CommitOrderId, which is very similar in
>> concept, for example.
>
> Do you think having this snapshot scheme would be helpful for Postgres-R?
Yeah, it could help to reduce patch size, after a rewrite to use such a CSN.
>> Or why do you need to tell apart aborted from in-progress transactions
>> by CSN?
>
> I need to detect aborted transactions so they can be discared during
> the eviction process, otherwise the sparse array will fill up. They
> could also be filtered out by cross-referencing uncommitted slots with
> the procarray. Having the abort case do some additional work to make
> xid assigment cheaper looks like a good tradeoff.
I see.
>>> Sparse buffer needs to be at least big enough to fit CSN slots for the
>>> xids of all active transactions and non-overflowed subtransactions. At
>>> the current level PGPROC_MAX_CACHED_SUBXIDS=64, the minimum comes out
>>> at 16 bytes * (64 + 1) slots * 100 = backends = 101.6KB per buffer,
>>> or 203KB total in the default configuration.
>>
>> A CSN is 8 bytes, the XID 4, resulting in 12 bytes per slot. So I guess
>> the given 16 bytes includes alignment to 8 byte boundaries. Sounds good.
>
> 8 byte alignment for CSNs is needed for atomic if not something else.
Oh, right, atomic writes.
> I think the size could be cut in half by using a base value for CSNs
> if we assume that no xid is active for longer than 2B transactions as
> is currently the case. I didn't want to include the complication in
> the first iteration, so I didn't verify if that would have any
> gotchas.
In Postgres-R, I effectively used a 32-bit order id which wraps around.
In this case, I guess adjusting the base value will get tricky. Wrapping
could probably be used as well, instead.
> The number of times each cache line can be invalidated is
> bounded by 8.
Hm.. good point.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: markus@bluegap.ch, ants@cybertec.at
Subject: Re: Proposal for CSN based snapshots
In-Reply-To: <51B6C97B.1070000@bluegap.ch>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox