On Fri, May 3, 2019 at 3:19 PM Chris Dent <cdent+os@anticdent.org> wrote:
On Fri, 3 May 2019, Eric Fried wrote:
Another alternative is having a "closure table" from where we can retrieve all the descendent rp ids of an rp without joining tables. but... online migration cost?
Can we consider these optimizations later, if the python-side solution proves non-performant?
My preference would be that we start with the simplest option (make multiple selects, merge them appropriately in Python) and, as Eric says, if that's not good enough, pursue the optimizations.
In fact, I think we should likely pursue the optimizations [1] in any case, but they should come _after_ we have some measurements.
Jay provided a proposed algorithm in [2].
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. We have a time slot tomorrow (Saturday May 3) at 13:30 to discuss
some of the finer points of implementing nested magic [3].
I'll try to be present. -Sylvain
[1] Making placement faster is constantly a goal, but it is a secondary goal.
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005432.htm...
[3] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent