From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, nicolas(dot)barbier(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, laurenz(dot)albe(at)wien(dot)gv(dot)at |
Subject: | Re: Serializable Isolation without blocking |
Date: | 2010-01-08 18:05:22 |
Message-ID: | 4B4773E2.6020209@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Kevin Grittner wrote:
> I had this flagged as needing a response, but it fell through the
> cracks yesterday. Apologies for the delayed response.
No problem.
> Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> When the Cahill paper talks about predicate locking, it *is* talking
> about what to lock with SIREAD locks, at least as I read it. If you
> see something to indicate otherwise, please share. (If I'm off base
> on understanding any of this, I'd sure like to get straightened out
> as soon as possible.)
I don't remember reading about predicate locking in the paper I read.
Either he didn't cover that in his first implementation (based on page
level locking), or I've simply re-used that part of my in-brain-memory.
> It was the way Sybase worked for ages, too. If you consider that
> you're locking both the heap and index pages read, it becomes clear
> that in order to add a row which conflicts with a predicate, you
> have to modify a page which would have been read to check the
> predicate.
Hm.. interesting, thanks for this quick explanation.
>> How about storing the SIREAD info in shared memory and using
>> dynamic granularity based on the conflict rate and available
>> memory? *duck*
>
> Don't duck. That's the plan. I really wish I was better at
> communicating these things. :-( See lock.c and the associated
> README and see if you don't think they would fit the bill.
Cool!
> Exactly. That's the plan. Implement it in the simplest form, then
> optimize.
Perfect!
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-01-08 18:07:11 | Re: RFC: PostgreSQL Add-On Network |
Previous Message | David E. Wheeler | 2010-01-08 18:05:10 | Re: RFC: PostgreSQL Add-On Network |