Open Stack

On Fri, May 3, 2019 at 3:19 PM Chris Dent <cdent+os at 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.html
>
> [3]
> http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html
>
> --
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190503/9774e668/attachment-0001.html>