<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2019 at 3:19 PM Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 3 May 2019, Eric Fried wrote:<br>
<br>
>> Another alternative is having a "closure table" from where we can<br>
>> retrieve all the descendent rp ids of an rp without joining tables.<br>
>> but... online migration cost?<br>
><br>
> Can we consider these optimizations later, if the python-side solution<br>
> proves non-performant?<br>
<br>
My preference would be that we start with the simplest option (make<br>
multiple selects, merge them appropriately in Python) and, as Eric<br>
says, if that's not good enough, pursue the optimizations.<br>
<br>
In fact, I think we should likely pursue the optimizations [1] in<br>
any case, but they should come _after_ we have some measurements.<br>
<br>
Jay provided a proposed algorithm in [2].<br>
<br></blockquote><div><br></div><div>That plan looks good to me, with the slight detail that I want to reinforce the fact that python usage will have a cost anyway, which is to drift us from the perfect world of having a distributed transactional model for free. This is to say, we should refrain *at the maximum* any attempt to get rid of SQL and use Python (or other tools) until we get a solid consensus on those tools being as efficient and as accurately possible than the current situation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We have a time slot tomorrow (Saturday May 3) at 13:30 to discuss<br>
some of the finer points of implementing nested magic [3].<br>
<br></blockquote><div><br></div><div>I'll try to be present.</div><div>-Sylvain</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] Making placement faster is constantly a goal, but it is a<br>
secondary goal.<br>
<br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005432.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005432.html</a><br>
<br>
[3] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html</a><br>
<br>
-- <br>
Chris Dent                       ٩◔̯◔۶           <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent                                         tw: @anticdent</blockquote></div></div>