On 18 July 2013 17:44, Martyn Russell <mar...@lanedo.com> wrote: > On 15/07/13 08:08, Jonatan Pålsson wrote: >> >> On 12 July 2013 18:52, Ivan Frade <ivan.fr...@gmail.com> wrote: >>> >>> Hi! >>> >>> If you are not using email, that ontology will be translated into some >>> tables in the database but they are never touched. It should not make big >>> difference. >>>> >>>> >> Aha, this is very good to know. It should mean I can keep several >> flattened ontologies side-by-side them impacting each other >> negatively. This is good! > > > Generally speaking, you want to aim for the least changes as possible to > achieve what you want. That way you keep closer to upstream and have less > maintenance burden. > > What's not clear to me is your targets or if you're looking for > optimisations out of curiosity. > > What do you want to improve, query or insert times? Disk or memory usage, > etc. etc. The list goes on. It's all possible, but you sacrifice something > else when you do this. > At this point, the optimizations are mostly out of curiosity, in order to establish a fastest possible insertion speed. I am looking for a way to insert the (most likely multimedia) metadata contents of a (probably) removable device as fast as possible. I realize lookup speeds may be negatively impacted by this, which is of course not ideal, but if kept "low" might be acceptable. I would have to evaluate, and, as you say, play with the sliding scale ;)
Lowering disk usage is also of interest, but I will keep these matters separate unless one seems to massively impact the other, and look at insertion/lookup speed first. I still haven't started looking at this however. Thanks for the input, and any other suggestions for improving insertion speed are greatly appreciated! -- Regards, Jonatan Pålsson Pelagicore AB Ekelundsgatan 4, 6th floor, SE-411 18 Gothenburg, Sweden _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
