I should have reread my response twice, lol. I rewrote the last sentence to make sense.
Yes, without a RETURN clause the function we are trying to benchmark will not be called, and naming all the variables in a CREATE clause with a significant amount of vertices created to measure performance would not be the most accurate test to how cypher would be used for most people. Did you run the query I provided once or multiple times? Looking at the original results, there were cases where the original version ran faster. We saw an improvement over average time. Either way, don't worry about the performance of the query I sent. The query I provided that dynamically runs the query in a function may have some issues affecting the results. Consult the thread titled "Benchmarking results' for a better way. We create value for our clients by connecting the world's data. Josh Innis Software Engineer Core R&D Team *P*: (831)278-0327 3945 Freedom Circle #260, Santa Clara, CA 95054 <https://www.google.com/maps/place/3945+Freedom+Cir+%23260,+Santa+Clara,+CA+95054/> bitnine.net On Mon, Sep 13, 2021 at 1:03 PM Josh Innis <joshin...@gmail.com> wrote: > Hi Viet, > > Yes, without a RETURN clause the function we are trying to benchmark will > not be called, and naming all the variables in a CREATE clause with a > significant amount of vertices created to measure performance would not be > the most accurate test to how cypher would be used for most people. > > Did you run the query I provided once or multiple times? Looking at the > original results, there were cases where the original version ran faster. > We saw an improvement over average time. Either way, don't worry about the > performance of the query I sent. The query I provided may also have an > issue where dynamically running the query in a function may have some > issues affecting the results. > > Consult the thread titled "Benchmarking results' for a better way. > > On Mon, Sep 13, 2021 at 7:31 AM VUONG QUOC Viet <vqv...@bitnine.net> > wrote: > >> Hi guys, >> I've followed John's suggestion on Friday, which was to combined multiple >> cypher queries into 1 long query, like this: >> SELECT * >> FROM cypher('test_graph', $$ >> CREATE(:Person{id: 123, name: 'Andres', title: 'Developer', city: >> 'Seattle'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Brian', title: 'Researcher', city: >> 'Munich'}) >> CREATE(:Person{id: 123, name: 'Viet', title: 'Dev', city: 'Hanoi'}) >> $$) as (a agtype); >> The problem is, if there's no RETURN clause, the function >> _agtype_build_vertex will not be invoked. I checked this with the >> debugger. >> However, if we want to have a RETURN clause, we have to name each vertex, >> like a, b, c, d, whatever..., which seems impossible when we want to run >> 100, 1000 and 10000 queries or even more. >> Also, I followed Josh's suggestions on how to use the loop. I made a new >> script for it and ran 100, 1000, 10000, 100000 queries and extracted the >> execution time automatically. The result, however, shocked me because the >> time for optimized code is actually larger than that of the original code. >> >> Original Optimized >> 100 queries 38.10308 40.473135 >> 1000 queries 268.219235 284.259025 >> 10000 queries 2354.88069 2436.623295 >> 100000 queries 21843.64663 22750.658105 >> I'm gonna need to find a ultimate solution for this and make sure about >> the >> repeatability as well. >> Best regards, >> >> Viet. >> >
