Please see comment at the bottom of this post.
On 08/07/16 10:48, Pete Stevenson wrote:
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 work.
Thank you,
Pete Stevenson
On Jul 7, 2016, at 3:43 PM, Simon Riggs <si...@2ndquadrant.com
<mailto: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/ <http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
In this list, the convention is to post replies at the end (with some
rare exceptions), or interspersed when appropriate, and to omit parts no
longer relevant.
The motivation of bottom posting like this: is that people get to see
the context before the reply, AND emails don't end up getting longer &
longer as people reply at the beginning forgetting to trim the now
irrelevant stuff at the end.
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
