On Tue, 28 Apr 2015 09:24:56 +0200 Dominique Devienne <ddevienne at gmail.com> wrote:
> On Tue, Apr 28, 2015 at 4:16 AM, James K. Lowden > <jklowden at schemamania.org> wrote: > > > A major hurdle is the memory model: because array-programming > > libraries normally mandate the data be in contiguous memory, > > there's a cost to converting to/from the DBMS's B+ tree. The more > > array-like the physical storage of the DBMS, the more it cedes > > transactional and update capability. > > Well, just look at how Oracle solved that problem. The row data > doesn't hold the blob itself, like in SQLite, but an index to > separate blob pages. This proverbial level of indirection brings > tremendous benefits, because you can then update a blob w/o having to > rewrite the whole blob (you copy the "blob" page(s) being updated > only, and copy the row into a new "data" page with an updated "blob > index" with just a few entries changed to point to the updated pages. Does Oracle provide access to the BLOB as a contiguous memory image in the Oracle server's virtual address space? The benefit you're describing reduces the I/O required to update the BLOB and to traverse the table without referencing it. That's a *very* old technique; it was available in Sybase in 1980s. To support use of arbitrary linear algebra functions on those BLOBs, they would have to supplied to user-defined functions in linear memory with known addresses. --jkl
