Re: [Jdbm-developer] MVCC in postgres: question about implementation experience?

[Alex B. <boi...@in...>]

My position on this is that MVCC benefits (e.g. readers never block
writers) generally outweight the performance advantage of locking.

I am not surprised at all to hear that locking performs better than MVCC
since most of the time databases are I/O-bound and MVCC implies same or
higher levels of I/O.   But I guess in the end, it's the access pattern
that dictates which approach is most performant.

alex


Kevin Day wrote:

> Bryan-
>  
> For what it's worth, I haven't yet seen an article that presents a
> conclusive argument for why locking would ever outperform MVCC.  The
> articles I've seen so far talk about advantages of locking over
> timestamping, but that is a completely different animal.
>  
> Here's a brief description of timestamping taken from [1]:
>  
>
>     In english, timestamping works by objects keeping track of the
>     youngest transaction to read or write the object - ie the largest
>     timestamp. Note however that the modified value is only written to
>     the value of the object when the transaction has committed. This
>     means that if a transaction attempts to read an object that was last
>     written by a transaction that hasn't yet committed, the reading
>     transaction has to wait until the writing transaction either
>     aborts or
>     commits the tentative version of the object, which can then be
>     returned to the reading transaction.
>
> The important piece of this is that the READING in timestamping has to
> wait, which would definitely lead to concurrency performance
> problems.  MVCC does not at all have this problem.
>  
>  
> I must have missed one of the articles you sent out that talks about
> MVCC restart times - would you mind resending it?
>  
> I'm pretty sure that restart costs between MVCC and locking should be
> roughly equivalent.  With a dbCache implementation on the front end,
> restart should just be the time required to rebuild the cache from the
> safe.
>  
>  
>  
> - K
>  
> [1]
> http://www.cogs.susx.ac.uk/users/ianw/teach/dist-sys/ds00-archive/0024.html
>  
>
> 	> Hello,
>
> I am working on a project (jdbm[1]) which is doing some research in
> concurrency control mechanisms.  It seems that MVCC is out-performed
> by locking due to restart costs.  Since postgres uses both MVCC and
> locking I was wondering how this played out?
>
> Based on my reading so far, locking will out perform MVCC (timestamp
> ordering in general) owing to restart costs.  It appears that the
> postgres implementation uses a mixture of locking and MVCC.  While I
> have seen some articles which use pre-declared write sets to avoid
> restart, I have not seen anything on mixing locking and MVCC together.
>
> More broadly jdbm is not a SQL database.  It provides byte[] records
> and some access path mechanisms (btree, hash table).  Unlike an OODBMS,
> jdbm does not provide transparency into the structure of a record (fields
> and links) and the application does not currently declare that structure
> to the record manager.  However, based on what I have read it seems that
> concurrency control in general requires some application level semantics
> in order to have high concurrency.  Do you have any sense whether MVCC
> would be a reasonable approach in this case?  Are there articles published
> on the approach to MVCC that was used in postgres?
>
> Thanks,
>
> -bryan
>
> [1] http://www.sourceforge.net/projects/jdbm
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>
> _______________________________________________
> Jdbm-developer mailing list
> Jdb...@li...
> <mailto:Jdb...@li...>
> https://lists.sourceforge.net/lists/listinfo/jdbm-developer
>
> <
>
> ------------------------------------------------------- This SF.net
> email is sponsored by: Splunk Inc. Do you grep through log files for
> problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________ Jdbm-developer mailing
> list Jdb...@li...
> https://lists.sourceforge.net/lists/listinfo/jdbm-developer