On Wed, Jun 19, 2024 at 8:32 AM Simon Horman <ho...@ovn.org> 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 <i.maxim...@ovn.org> 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 <m...@redhat.com> > > > > --- > > > > 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. -M > > ... > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
