Next: Inferred knowledge Up: Implementation Previous: Modules of the system Contents
There are two scenarios of downloading Extensional Knowledge from the database to the inference engine:
For the first case the whole Extensional Knowledge is downloaded and acquired by the inference engine as its own. It has a significant communication and memory footprint. All relations which are denoted as source of Extensional Knowledge for the given Jelly View have to be queried, and their states have to be sent to the inference engine. The more tuples in the relations, the more time is necessary for the download, and more memory will be occupied. The inference process could not be started before entire Extensional Knowledge is downloaded.
The second approach is to download a tuple, only when it is needed. If the inference engine tries to unify some goal with the clause of a predicate provided by the Internal Matching then the database is queried, the tuple is returned and the unification takes place. If the downloaded tuple does not unify with the goal, then another tuple is downloaded, and so on.
Downloading on demand should be more efficient then the preload downloading, but there is another, hidden issue here. The inference engine might call the External Matching predicate for more than one goal. In that case, separate clauses of the same predicate have to be kept for the separate goals . If the preloading scenario is used then the inference engine is aware of it and does not duplicate data. Both goals work on the same data. For the on demand scenario, the inference engine is not aware of it and uploads data from the database as many times as many goals for the given predicate there are.
The preliminary tests indicated that the preloading scenario is far more efficient then the on demand one. The following example illustrates it. There is a relation expressing a tree structure (the same relation is used in one of the examples, see Chapter 12). The relation consists of 17 tuples.
An ordinary SELECT query, displaying all the tuples takes 0.215 seconds (the query is issued through the ODBC interface). Running the same query through the ReDaReS takes 0.281 seconds (no Jelly Views are involved). Issuing a query which involves a Jelly View, which browses recursively the tree structure takes: 0.320 seconds for the preloading scenario, and 2.271 seconds for the on demand scenario, which is about ten times slower, than the preloading. The above data are presented in Table 11.3 for better comprehension. The first entry in the table refers to a SELECT query through the native PostgreSQL11.2 interface.
|
The default method is chosen to be the preload scenario, however the on demand is also available as a configurable option.
Igor Wojnicki 2005-11-07