On 07/21/2016 02:43 PM, Carl Baldwin wrote:
None of these operations are expected to be very contentious and
performance hasn't really been a concern yet. If it were a big concern,
I'd be very interested in the GiST index solution because, as I
understand it, detecting overlap without that capability requires a
linear search through the existing records. But, GiST index capability
isn't ubiquitous which makes it difficult to get excited about for
practical purposes. I do have an academic interest in it. Computational
geometry used to be a hobby of mine when I worked on tools for physical
design of microchips. I've been telling people for years that I thought
it'd be cool if databases had some facility for indexing potentially
overlapping ranges in one or more dimensions. This looks like some
pretty cool stuff.
Can you think of any other operations in Neutron -- or elsewhere in
OpenStack -- which will benefit from these new functions? I'll be
honest. Without some compelling benefit, it may be very difficult to
swallow the pill of dealing with special case code in each kind of DB
for this capability. But, if it is abstracted sufficiently by oslo db,
it might be worth looking at down the road. The changes to adopt such
functionality shouldn't be too difficult.
Well let me reiterate the idea, which is that:
1. we add features to oslo.db so that the use of a custom stored
function is not a big deal
2. we add features to oslo.db that are based on using triggers, special
constraints, or Gist indexes, so that the use of a database constraint
that needs this kind of thing is not a big deal
3. the first proof of concept for this, is a CIDR function / trigger for
this one reported issue in Neutron.
Now the question is, "can I think of any operation in openstack, besides
this one, that would benefit from a custom stored function or a
specialized constraint". The answer for me is "not specifically but i
bet if I started looking, I would". Anytime there's an application
loading some rows of data out of a table, doing some calculations on it,
then dealing with a subset of those rows as a result, is a candidate for
#1 (in fact I have some vague recollection of seeing some patch in
Neutron that had this issue, it was the reason that compare-and-swap
could not be used). Anytime an application is trying to insert rows
into a table which should be rejected based on some criteria beyond
"unique key", that's a candidate for #2 - perhaps the plethora of
UUID-based recipes throughout openstack in some cases could be better
stated by more data-driven constraints.
If we were to decide that the Neutron issue right here doesn't need any
changes, then I would be fine abandoning this initiative for now. But
as it stands, there seems to be a need to either do this change, *or*
add a new UUID column to the subnets table, and basically I'm hoping to
start steering the boat away from the island of
add-a-new-column-everytime-theres-a-concurrency-problem.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
