Hi Andrew > what should a no_search latch return?
For latch=0/no_search, the table should look as inserted (i.e. like a regular table). I was just wondering if you'd also set "no_search" as the default, but I reckon it might be better to use an empty string or NULL rather than no_search. Can you change that without causing hassles elsewhere? > Given the data below, there is only one directed link between vertexes > 1,2 and one directed link between vertexes 2,1 > > So by my logic if you are looking for 'things' with a destid of vertex > 2 and and source vertext of 1 then only one row should be returned? yes. > INSERT INTO graph_base(from_id, to_id) VALUES (1,2), (2,1); > INSERT INTO graph_base(from_id, to_id) VALUES (1,3), (3,1); > INSERT INTO graph_base(from_id, to_id) VALUES (3,4), (4,3); > INSERT INTO graph_base(from_id, to_id) VALUES (5,6), (6,5); > > SELECT * FROM graph WHERE latch='no_search' and destid=2 and origid=1; > > yields > > latch origid destid weight seq linkid > no_search 1 2 1 3 1 > no_search 1 2 1 2 3 > no_search 1 2 1 1 2 > > > (And simlar for the integer latch equivalent) > > latch origid destid weight seq linkid > 0 1 2 1 3 1 > 0 1 2 1 2 3 > 0 1 2 1 1 2 Without a latch command, seq/linkid should come back NULL. So it appears the computation engine is doing some path search there, as there is an seq. The result above is wrong, but I'm very curious what it is actually doing? (which bit of code is getting executed?) You could install a MariaDB 5.3 to compare behaviour with v2, but asking me works also ;-) Without a latch, you can return either any rows that match the origid/destid/weight conditions (as they're the only real columns), or you can be lazy and return everything - the server core will filter it for you according to the WHERE conditions! The latter is useful because it allows us to cheaply return the correct result for constructs like WHERE origid BETWEEN 10 and 20 without processing pushdown conditions (something we will want to do for other tasks, such as restricting search depth, but that's a separate gig). Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Australian peace of mind for your MySQL/MariaDB infrastructure. Follow us at http://openquery.com/blog/ & http://twitter.com/openquery -- Mailing list: https://launchpad.net/~oqgraph-dev Post to : oqgraph-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~oqgraph-dev More help : https://help.launchpad.net/ListHelp
