Good info, thanks for the note. Agreed that it is difficult to pull things
apart to isolate these features for offload — so actually running experiments
with offload is not possible, as you point out (and for other reasons).
Maybe I could figure out the lines of code that add versions into a table and
then those that collect old versions (they do get collected, right?). Anyway,
thought being I could profile while running TPC-C or similar. I was hoping that
someone might be able to jump on this with a response that they already did
something similar. I know that Stonebraker has done some analysis along these
lines, but I’m looking for an independent result that confirms (or not) his
> On Jul 7, 2016, at 3:43 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 7 July 2016 at 20:50, Pete Stevenson <etep.nosnev...@gmail.com
> <mailto:etep.nosnev...@gmail.com>> wrote:
> Hi Simon -
> Thanks for the note. I think it's fair to say that I didn't provide enough
> context, so let me try and elaborate on my question.
> I agree, MVCC is a benefit. The research angle here is about enabling MVCC
> with hardware offload. Since I didn't explicitly mention it, the offload I
> refer to will respect all consistency guarantees also.
> It is the case that for the database to implement MVCC it must provide
> consistent read to multiple different versions of data, i.e. depending on the
> version used at transaction start. I'm not an expert on postgresql internals,
> but this must have some cost. I think the cost related to MVCC guarantees can
> roughly be categorized as: creating new versions (linking them in), version
> checking on read, garbage collecting old versions, and then there is an
> additional cost that I am interested in (again not claiming it is unnecessary
> in any sense) but there is a cost to generating the log.
> Thanks, by the way, for the warning about lab vs. reality. That's why I'm
> asking this question here. I want to keep the hypothetical tagged as such,
> but find defensible and realistic metrics where those exist, i.e. in this
> instance, we do have a database that can use MVCC. It should be possible to
> figure out how much work goes into maintaining that property.
> PostgreSQL uses a no overwrite storage mechanism, so any additional row
> versions are maintained in the same table alongside other rows. The MVCC
> actions are mostly mixed in with other aspects of the storage, so not
> isolated much for offload.
> Oracle has a different mechanism that does isolate changed row versions into
> a separate data structure, so would be much more amenable to offload than
> PostgreSQL, in its current form.
> Maybe look at SLRUs (clog etc) as a place to offload something?
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services