On Wed, Jun 19, 2024 at 08:35:20AM -0400, Mike Pattrick wrote: > On Wed, Jun 19, 2024 at 8:32 AM Simon Horman <[email protected]> wrote: > > > > On Mon, Jun 17, 2024 at 01:11:28PM -0400, Mike Pattrick wrote: > > > On Mon, Jun 3, 2024 at 2:01 PM Ilya Maximets <[email protected]> wrote: > > > > > > > > On 6/3/24 06:20, Mike Pattrick wrote: > > > > > Currently all OVSDB database queries except for UUID lookups all > > > > > result > > > > > in linear lookups over the entire table, even if an index is present. > > > > > > > > > > This patch modifies ovsdb_query() to attempt an index lookup first, if > > > > > possible. If no matching indexes are present then a linear index is > > > > > still conducted. > > > > > > > > > > Reported-at: https://issues.redhat.com/browse/FDP-590 > > > > > Signed-off-by: Mike Pattrick <[email protected]> > > > > > --- > > > > > NEWS | 3 ++ > > > > > ovsdb/query.c | 102 > > > > > +++++++++++++++++++++++++++++++++++---- > > > > > ovsdb/row.h | 28 +++++++++++ > > > > > ovsdb/transaction.c | 27 ----------- > > > > > tests/ovsdb-execution.at | 34 ++++++++++++- > > > > > tests/ovsdb-server.at | 2 +- > > > > > tests/ovsdb-tool.at | 2 +- > > > > > 7 files changed, 159 insertions(+), 39 deletions(-) > > > > > > > > Hi, Mike. Thanks for the patch. > > > > > > > > Besides what Simon asked, the patch has a few other issues: > > > > > > > > 1. Lookup is performed only on the committed index and it doesn't > > > > include > > > > rows that are in-flight in the current transaction. > > > > > > > > Unlike rows in a hash table, indexes are updated only after the whole > > > > transaction is committed. With this change we'll not be able to find > > > > newly added rows. > > > > > > > > Another thing related to this is that it is allowed to have > > > > duplicates > > > > within a transaction as long as they are removed before the > > > > transaction > > > > ends. So it is possible that multiple rows will satisfy the > > > > condition > > > > on indexed columns while the transaction is in-flight. > > > > > > > > Consider the following commands executed in a sandbox: > > > > > > > > # ovs-vsctl set-manager "tcp:my-first-target" > > > > # ovsdb-client transact unix:$(pwd)/sandbox/db.sock ' > > > > ["Open_vSwitch", > > > > {"op": "select", > > > > "table": "Manager", > > > > "columns": ["_uuid", "target"], > > > > "where": [["target", "==", "tcp:my-first-target"]]}, > > > > {"op": "insert", > > > > "table": "Manager", > > > > "uuid-name": "duplicate", > > > > "row": {"target": "tcp:my-first-target"}}, > > > > {"op": "select", > > > > "table": "Manager", > > > > "columns": ["_uuid", "target"], > > > > "where": [["target", "==", "tcp:my-first-target"]]}, > > > > {"op": "delete", > > > > "table": "Manager", > > > > "where":[["_uuid","==",["named-uuid","duplicate"]]]}, > > > > {"op": "select", > > > > "table": "Manager", > > > > "columns": ["_uuid", "target"], > > > > "where": [["target", "==", "tcp:my-first-target"]]}]' > > > > > > > > Transaction must succeed. The first selection should return 1 row, > > > > the second should return both duplicates and the third should again > > > > return one row. > > > > > > This is a good point, I hadn't anticipated this use-case but it does > > > have a large impact on this change. After working through a few > > > implementations, I wasn't able to find a solution that wasn't overly > > > complex. For the next version, I've instead opted to exclude indexed > > > lookups from transactions that modify the associated row. > > > > > > The next version should address this and the other feedback. > > > > Hi Mike, > > > > My inbox is confusing me somewhat, > > are you planing a v3 of this patch? > > I seem to have sent the v3 as v2 by mistake. I will resubmit.
Thanks, I think that would help :) _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
