Hi Andrew
> NO_SEARCH causes different behaviour depending on how it is used:
>
> In my branch lines 707-749 of graphcore.cc
>
> NO_SEARCH alone returns a vertices_cursor(share)
>
> but
>
> NO_SEARCH with HAVE_DEST does
Possibly this was an attempt by Antony to speed up queries that do have either
or both those restrictions.
Antony?
Regards,
Arjen.
> if ((op & HAVE_DEST) &&
> (cursor || (cursor= new (std::nothrow) stack_cursor(share))) &&
> dest)
> {
> graph_traits<Graph>::in_edge_iterator ei, ei_end;
> for (boost::tuples::tie(ei, ei_end)= in_edges(*dest, share->g); ei
> != ei_end; ++ei)
> {
> Vertex v= source(*ei, share->g);
> static_cast<stack_cursor*>(cursor)->
> results.push(reference(++seq, v, *ei,
> get(boost::edge_weight, share->g, *ei)));
> }
> }
>
> NO_SEARCH with HAVE_ORIG does
>
> if ((cursor= new (std::nothrow) stack_cursor(share)) && orig)
> {
> graph_traits<Graph>::out_edge_iterator ei, ei_end;
> for (boost::tuples::tie(ei, ei_end)= out_edges(*orig, share->g); ei
> != ei_end; ++ei)
> {
> Vertex v= target(*ei, share->g);
> static_cast<stack_cursor*>(cursor)->
> results.push(reference(++seq, v, *ei,
> get(boost::edge_weight, share->g, *ei)));
> }
> }
>
> and falls through to the HAVE_DEST handler above
>
> I dont (yet) understand the above graph code, but I'll instrument this
> to see
> which is being called, although an educated guess is that the third
> case is if
> I assume that HAVE_ORIG and HAVE_DEST are derived from columns in the
> query...
>
> In the process of that I should further be able to learn how the boost
> graph
> code actually works
>
>
> It seems that basic.test has no queries that exercise no_search
> without dest
> or orig, so I'll add some. Same goes for no latch there are no tests
> yet either
>
> --Andrew
>
>
> On 29/05/13 08:08, Arjen Lentz wrote:
> > 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.
>
>
> --
> 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
--
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
