blob: 8f28856543666f60a25404c5133ebed515fdeccd (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
/*! \page sql_mapping Mapping SQL onto the WiredTiger API
@todo decide whether to keep this page, if so, fill it out
An RDBMS has the SQL language, a parser and a query planner. All of them
sit on top of WiredTiger, as they would on top of any key-value store.
The difference with WiredTiger's API is that the query plan is going to be
based on fundamental operations including:
# sequential scan through a range;
# join (various flavors);
# sort (group by);
# projection, and so on.
Those operations would be implemented as different WiredTiger cursor types,
using WT_CONNECTION::add_cursor_type.
The cursor types could be implemented as one or more extensions, loaded
automatically whenever the database is opened for the first time. Then the
cursor types would always be there, and the query planner just asks for a
cursor that combines together data from various other cursors and comes out as
a set of key/data pairs it can deal with.
With the right set of special cursor types are implemented, one cursor could
return the SQL result set. That is, combining cursors would implement a
query plan. And that could happen over a socket, mixing local processing
with server-side processing.
This same interface could deal with many types of compression, transforming
data on the fly in various ways (like views), and so on.
*/
|
