Thanks Geert ! The discussion is on the right track . As per Query profiling If I go for the option 2 , no doubt I am getting performance improvement. But in this scenario it is hard to trace out If I need to create element-value-query or element-range-query .
option 2 To implement this consider application is sending criteria as follow <criteria> <criterion> <element name="[element name]" type="[Value Query OR Word Query OR Range Query]"> <values> <value>californa</value> <value>californa</value> </values> </element> <field name="[field name]" type="[ Word Query]"> <values> <value>USACA</value> <value>USAFA</value> </values> </field> </criterion> </criteria> Based on the above XML I can trace out if the query is required to be element-value / field-word-query. But the drawback with this approach is that application required the knowledge this constraint definition which is improper in terms of architecture. option 1 On the other hand if I use search:parse irrespective of constraint type application will simply send "constr1:value1 AND constr2:value2" . Application do not need to bother about constr1 and constr2 definitions (element-value, element-range, field-word). Can I use the constraint definition concept (option 1) for option 2. If so my cts:query (kind of constraint-query) which will be more performance efficient & generalized. Thanks in advance ! Abhishek Srivastav Systems Engineer Tata Consultancy Services Cell:- +91-9883389968 Mailto: abhishek5...@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ From: Geert Josten <geert.jos...@daidalos.nl> To: General MarkLogic Developer Discussion <general@developer.marklogic.com> Date: 06/28/2011 12:28 PM Subject: Re: [MarkLogic Dev General] Query Parsing Sent by: general-boun...@developer.marklogic.com Hi Abhishek, One of the features of search:search is that it can parse the search query. That requires string parsing, which usually gets exponentially slower with the length of the string that needs to be parsed. Also, search:search translates to something expressed in cts on the backend. So, if you know really well what needs to be done, scenario 2 is likely to be faster. But you have to construct your query somehow, so that will take performance anyhow. If you end up doing string parsing yourself, don?t bother and use search:search. It also comes with additional goodies, you probably don?t want to reinvent if you need them.. Kind regards, Geert Van: general-boun...@developer.marklogic.com [ mailto:general-boun...@developer.marklogic.com] Namens Abhishek53 S Verzonden: dinsdag 28 juni 2011 7:28 Aan: General MarkLogic Developer Discussion Onderwerp: Re: [MarkLogic Dev General] Query Parsing Danny Thanks for your reply . My question is more inclined to the performance of parsing the query text using search:parse API OR creating the element-value-query with the values.Query profiling suggest that the process of parsing the query text using search:parse is taking more time than creating the element-value-query. Below is my testing scenario Scenario 1 Using search:parse import module namespace search = "http://marklogic.com/appservices/search" at "/MarkLogic/appservices/search/search.xqy"; let $options := <options xmlns="http://marklogic.com/appservices/search"> <constraint name="suggest" facet="true"> <range type="xs:string"> <element name="suggest"/> </range> </constraint> </options> return search:parse('suggest:"kolkata" OR suggest:"kolkata.......to 10000 times"',$options) (: Taking more time to parse the query :) Scenario 2 cts:element-value-query(xs:QName("suggest"),("kolkata", "kolkata".......to 10000 times)) (: More efficient :) Let me know your idea ! Thanks & Regards Abhishek Srivastav Systems Engineer Tata Consultancy Services Cell:- +91-9883389968 Mailto: abhishek5...@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ From: Danny Sokolsky <danny.sokol...@marklogic.com> To: General MarkLogic Developer Discussion <general@developer.marklogic.com> Date: 06/28/2011 12:15 AM Subject: Re: [MarkLogic Dev General] Query Parsing Sent by: general-boun...@developer.marklogic.com I am not sure I understand your question, but I?ll take a stab. I would guess that using search:parse would be more efficient, but more importantly, it will get you the query you want. Otherwise you will have to reimplement it to parse the constraints. Is it taking a long time? Have you tried profiling it to see where it is spending time? -Danny From: general-boun...@developer.marklogic.com [ mailto:general-boun...@developer.marklogic.com] On Behalf Of Abhishek53 S Sent: Monday, June 27, 2011 11:05 AM To: General MarkLogic Developer Discussion Cc: neha_punj...@mcgraw-hill.com Subject: [MarkLogic Dev General] Query Parsing Hi Folks (1) Currently my search application input is query text. eg "constr1:value1 OR constr2:value2".This requires to be parsed separately using search:parse API. The output query xml is converted to cts:query and then passed to the additional query (required to be excluded for highlighting). The query text can be very large and complex. (2) In spite of sending the query text if the application send the constraint values then the cts:query can be created and directly send to the additional query. This can save the additional step of parsing the query. e.g. additional-query = cts:or-query(($some-xml//values)) My area of concern is which would be more efficient term of performance 1. Creating cts query (2) from the values sent from application 2. Parsing the query using search:parse (1) and then casting to cts:query Thanks in advance ! Abhishek Srivastav Systems Engineer Tata Consultancy Services Cell:- +91-9883389968 Mailto: abhishek5...@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you _______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general