On Mon, Nov 24, 2014 at 3:51 AM, Heikki Linnakangas
wrote:
> Ok, applied those extra paragraphs now, and marked as "committed" in the
> commitfest.
Thanks!
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On 09/27/2014 09:36 AM, Peter Geoghegan wrote:
On Fri, Sep 26, 2014 at 11:34 PM, Amit Kapila wrote:
I have observed that this patch is in 'Needs Review' state for
next CF. Do you expect any further review from myside? I think
we can use text recommended by Heikki and after that if you
feel so
On Fri, Sep 26, 2014 at 11:34 PM, Amit Kapila wrote:
> I have observed that this patch is in 'Needs Review' state for
> next CF. Do you expect any further review from myside? I think
> we can use text recommended by Heikki and after that if you
> feel something more is still required, then you c
On Fri, Sep 12, 2014 at 10:54 PM, Peter Geoghegan wrote:
>
> It isn't. It's a minor point, originally raised by Amit.
I have observed that this patch is in 'Needs Review' state for
next CF. Do you expect any further review from myside? I think
we can use text recommended by Heikki and after tha
On Fri, Sep 12, 2014 at 2:45 PM, Heikki Linnakangas
wrote:
>
> On 09/11/2014 11:47 PM, Peter Geoghegan wrote:
>>
>> On Tue, Sep 9, 2014 at 12:01 AM, Heikki Linnakangas
>> wrote:
+ Although it could be argued that Lehman and Yao isn't followed to the
+ letter because single pages ar
On Fri, Sep 12, 2014 at 12:39 PM, Kevin Grittner wrote:
> It's been a while since I read that paper, but my recollection is
> that they assumed that each process or thread looking at a buffer
> would have its own private copy of that buffer, which it could be
> sure nobody was changing (even if th
Peter Geoghegan wrote:
> The introductory paragraph of L&Y says the following:
>
> "Our solution compares favorably with earlier solutions in that the
> locking scheme is simpler (no read-locks are used) and only a (small)
> constant number of nodes are locked by any update process at any given
>
On Fri, Sep 12, 2014 at 10:10 AM, Robert Haas wrote:
> Gosh, I think you're making this way more complicated than it needs to
> be. My interpretation of the above statement was that they knew
> individual page reads and writes would need to be made atomic -
> probably using some form of simple lo
On Fri, Sep 12, 2014 at 12:57 PM, Peter Geoghegan wrote:
> On Fri, Sep 12, 2014 at 2:15 AM, Heikki Linnakangas
> wrote:
>> Amit: did you notice that paragraph in the README? If not, and now that you
>> have read it, does that paragraph make things clear? If that's not enough,
>> what do you think
On Fri, Sep 12, 2014 at 2:15 AM, Heikki Linnakangas
wrote:
> Amit: did you notice that paragraph in the README? If not, and now that you
> have read it, does that paragraph make things clear? If that's not enough,
> what do you think is missing?
Amit raised the fact that L&Y say that no read lock
On 09/11/2014 11:47 PM, Peter Geoghegan wrote:
On Tue, Sep 9, 2014 at 12:01 AM, Heikki Linnakangas
wrote:
+ Although it could be argued that Lehman and Yao isn't followed to the
+ letter because single pages are read locked as the tree is descended,
+ this is at least necessary to support delet
On Tue, Sep 9, 2014 at 12:01 AM, Heikki Linnakangas
wrote:
>> + Lehman and Yao don't require read locks, but assume that in-memory
>> + copies of tree pages are unshared.
> This is the existing paragraph, just moved to different place in the README.
That's right - it seemed to make just as much
On 09/07/2014 05:58 AM, Peter Geoghegan wrote:
+ Lehman and Yao don't require read locks, but assume that in-memory
+ copies of tree pages are unshared. Postgres shares in-memory buffers
+ among backends. As a result, we do page-level read locking on btree
+ pages in order to guarantee that no
On Tue, Jul 22, 2014 at 10:49 PM, Peter Geoghegan wrote:
>> Basically I think it will be better if you can explain in bit more detail
>> that
>> how does "right-links at all levels and high-key" helps to detect and
>> recover from concurrent page splits.
>
> You might be right about that - perhaps
On Thu, Jul 24, 2014 at 9:28 AM, Peter Geoghegan wrote:
> On Wed, Jul 23, 2014 at 8:52 PM, Amit Kapila
wrote:
> > As such there is no problem in saying the way you have mentioned, but
> > I feel it would be better if we can mention the mechanism of
_bt_search()
> > as quoted by you upthread in th
On Wed, Jul 23, 2014 at 8:52 PM, Amit Kapila wrote:
> As such there is no problem in saying the way you have mentioned, but
> I feel it would be better if we can mention the mechanism of _bt_search()
> as quoted by you upthread in the first line.
> "> In more concrete terms, _bt_search() releases
On Wed, Jul 23, 2014 at 11:19 AM, Peter Geoghegan wrote:
> On Tue, Jul 22, 2014 at 8:59 PM, Amit Kapila
wrote:
> > Okay, but how does this justify to add below new text in README.
> > + Even with these read locks, Lehman and Yao's approach obviates the
> > + need of earlier schemes to hold multip
On Tue, Jul 22, 2014 at 8:59 PM, Amit Kapila wrote:
> Okay, but how does this justify to add below new text in README.
> + Even with these read locks, Lehman and Yao's approach obviates the
> + need of earlier schemes to hold multiple read locks concurrently when
> + descending the tree as part of
On Tue, Jul 22, 2014 at 5:39 PM, Tom Lane wrote:
> IIRC, the README was written on the assumption that you'd already read
> L&Y. If this patch is mostly about not assuming that, why not?
L&Y made the same mistake that the authors of most influential papers
make - they never get around to telling
On Wed, Jul 23, 2014 at 5:58 AM, Peter Geoghegan wrote:
> On Mon, Jul 21, 2014 at 9:55 PM, Amit Kapila
wrote:
> > The above indicates 2 things:
> > a. L & Y doesn't need to hold read locks concurrently.
> > b. Advantage of right-links at all levels and "high-key".
> >
> > As per my understanding,
Peter Geoghegan writes:
> Right. It seems like the nbtree README is very shy about telling us
> what the point of all this extra work is.
IIRC, the README was written on the assumption that you'd already read
L&Y. If this patch is mostly about not assuming that, why not?
On Mon, Jul 21, 2014 at 9:55 PM, Amit Kapila wrote:
> There is a mention about the race condition where it needs to move right
> in another caller (_bt_search) of _bt_moveright() as well.
>
> /*
> * Race -- the page we just grabbed may have split since we read its
> * pointer in the parent (or met
On Tue, May 27, 2014 at 1:52 AM, Peter Geoghegan wrote:
>
> While talking to various people during pgCon, I was reminded that the
> nbtree README does a poor job of explaining the actual practical
> advantages of L&Y from a high level. The "move right" trick is
> initially mentioned only as an adj
On Wed, Jul 2, 2014 at 8:14 PM, Abhijit Menon-Sen wrote:
> Well, to be fair, the original patch was posted to the list more than a
> month ago, and it should have been in this CF. But… it wasn't. And now
> after more than two weeks into this CF, I don't think it should be.
Is that how the rule is
At 2014-07-03 11:59:21 +0900, michael.paqu...@gmail.com wrote:
>
> +1. Even if it is just a doc patch, it has been submitted after 6/15,
> which was the CF1 deadline.
Well, to be fair, the original patch was posted to the list more than a
month ago, and it should have been in this CF. But… it wasn
On Thu, Jul 3, 2014 at 11:40 AM, Abhijit Menon-Sen wrote:
> At 2014-07-02 17:24:06 -0700, p...@heroku.com wrote:
>>
>> I've added this to the ongoing commitfest.
>
> I don't actually understand why you were able to do that (seeing as this
> CF is no longer open for new patches). Trivial or not, I
At 2014-07-02 17:24:06 -0700, p...@heroku.com wrote:
>
> I've added this to the ongoing commitfest.
I don't actually understand why you were able to do that (seeing as this
CF is no longer open for new patches). Trivial or not, I think at this
point it should go into the next one. Or it should be
On Mon, May 26, 2014 at 1:22 PM, Peter Geoghegan wrote:
> I think that this isn't enough. Attached patch proposes to add a small
> paragraph at the top of the nbtree README, to clarify the advantages
> of L&Y from a high level.
I've added this to the ongoing commitfest.
--
Peter Geoghegan
--
While talking to various people during pgCon, I was reminded that the
nbtree README does a poor job of explaining the actual practical
advantages of L&Y from a high level. The "move right" trick is
initially mentioned only as an adjunct to a discussion of the
special-case handling of root page spli
29 matches
Mail list logo
