Dear Seref, At moment we do not support AQL, mainly because none of our current partners/developers are asking for it. We have discussed using AQL internally several (lots of-) times, but also with for instance Ian.
If this changes, so if there is a need for AQL, we could easily support it. Its just a matter of development. In that case our architecture is to convert AQL to SQL, and go from there. Regards, Jan-Marc Op di 26 jan. 2016 om 12:26 schreef Seref Arikan < [email protected]>: > Thanks, > My feelings for postgresql are well known, it is a great piece of code. > Final question, do you support AQL with your current design? > > On Tue, Jan 26, 2016 at 10:40 AM, Jan-Marc Verlinden < > [email protected]> wrote: > >> Hi Seref, >> >> We tested with lots of queries, not with large datasets (tens of >> thousands) within the system itself. But given the nature of the "normal" >> relational DB schema and queries, this should be no problem at all. It's >> good old postgres..:-). >> >> Jan-Marc >> >> Op di 26 jan. 2016 om 10:53 schreef Seref Arikan < >> [email protected]>: >> >>> Hi Jan-Marc, >>> >>> To clarify: when you say huge: do you mean that the result set is huge, >>> or the the amount of existing data is huge? Are you able to comment on how >>> query performance changes/stays the same when the result set size begins to >>> grow? >>> >>> On Tue, Jan 26, 2016 at 9:38 AM, Jan-Marc Verlinden < >>> [email protected]> wrote: >>> >>>> I believe your paper is about performance of an openEHR based system >>>> with a relational database. It does not argues if this is the right >>>> approach. And specifically on the performance we could not agree >>>> more...:-). >>>> >>>> In the past year we worked on three different versions, all completely >>>> openEHR compliant. We compared them, so I believe we are entitled to >>>> discuss. Let's see: >>>> >>>> 1. Our first version was Java based with a postgres DB, everything >>>> stored as path/values. >>>> Every query would take about a second. We did not even try complex >>>> queries..:-). Also the GUI side did not know what to do with the >>>> pathvalues. >>>> 2. Second version was completely XML based, lots of Java with an >>>> Exist DB. This version can be found in GitHub. >>>> Results: a single query over 900 records took 100ms. But the scary >>>> part was that performance exploded linear, so 90000 would take about 10 >>>> seconds, even for the most simple (already indexed and optimized) query. >>>> 3. Our current stack converts archetypes to an Object model and >>>> persists this model to postgres. Indeed this needs some fancy tricks >>>> (@Thomas), but it's doable...:-). >>>> Performance is comparable with the findings in the paper, even with >>>> huge queries. Performance is steady at about 1 to 3ms per query. No >>>> optimization done yet, is not yet needed but could/will make it even >>>> faster. >>>> >>>> Cheers, Jan-Marc >>>> >>>> Op di 26 jan. 2016 om 09:55 schreef 吕旭东 <[email protected]>: >>>> >>>>> Dear all, >>>>> >>>>> I just found there are lots of comments on our recent paper. Thanks >>>>> for all these comments, I will read them and reply later. >>>>> >>>>> @Shinji, Of course the slides could be shared. >>>>> >>>>> Regards >>>>> Xudong >>>>> >>>>> 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI <[email protected]>: >>>>> >>>>>> Hi Ian and all, >>>>>> >>>>>> We, openEHR Japan had an unconference with Dr Lu and he gave us a >>>>>> presentation for us about this research. >>>>>> I will ask him if the slides would be shareble. >>>>>> >>>>>> Shinji KOBAYASHI >>>>>> >>>>>> 2016-01-25 22:04 GMT+09:00 Ian McNicoll <[email protected]>: >>>>>> >>>>>>> Interesting paper from China >>>>>>> >>>>>>> >>>>>>> http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0 >>>>>>> >>>>>>> Ian >>>>>>> >>>>>>> Dr Ian McNicoll >>>>>>> mobile +44 (0)775 209 7859 >>>>>>> office +44 (0)1536 414994 >>>>>>> skype: ianmcnicoll >>>>>>> email: [email protected] >>>>>>> twitter: @ianmcnicoll >>>>>>> >>>>>>> Co-Chair, openEHR Foundation [email protected] >>>>>>> Director, freshEHR Clinical Informatics Ltd. >>>>>>> Director, HANDIHealth CIC >>>>>>> Hon. Senior Research Associate, CHIME, UCL >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openEHR-technical mailing list >>>>>>> [email protected] >>>>>>> >>>>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openEHR-technical mailing list >>>>>> [email protected] >>>>>> >>>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>>>> >>>>> >>>>> _______________________________________________ >>>>> openEHR-technical mailing list >>>>> [email protected] >>>>> >>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>>> -- >>>> >>>> Jan-Marc Verlinden >>>> MedVision (mobile) >>>> >>>> *MedVision BV* >>>> Aagje Dekenkade 71 >>>> 2251 ZV, Voorschoten >>>> www.medvision360.com >>>> >>>> This e-mail message is intended exclusively for the addressee(s). >>>> Please inform us immediately if you are not the addressee. >>>> >>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> [email protected] >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> -- >> >> Jan-Marc Verlinden >> MedVision (mobile) >> >> *MedVision BV* >> Aagje Dekenkade 71 >> 2251 ZV, Voorschoten >> www.medvision360.com >> >> This e-mail message is intended exclusively for the addressee(s). Please >> inform us immediately if you are not the addressee. >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Jan-Marc Verlinden MedVision (mobile) -- *MedVision BV* Aagje Dekenkade 71 2251 ZV, Voorschoten www.medvision360.com This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
