4 ms·
SQL queries return data from tables. The abstract does mention that one downside of this is that the result of the query has to be constructed in memory, result
by fyrn_ 3y ago
SQL queries return data from tables.
The abstract does mention that one downside of this is that the result of the query has to be constructed in memory, resulting in a lot of copying.
This is particularly apparent for joins, where some join types can produce much more data than all their input tables combined.
I don't see how this is "return something other than a relation" they are pretty specific about what they mean and what benefits it can bring
- karmakaze 3y ago> Our approach has clear semantics, i.e. our extended SQL returns subsets of all tables with only those tuples that would be part of the traditional (single-table) query result set, however without performing any denormalization through joins. Yes, that sounds just like a GraphQL connection result with associated nested connections. I believe that there's link deduplication for GraphQL which can also be enabled to avoid the copies. The main difference is avoiding multiple round-trips--one for each table--which within a datacenter network doesn't add a whole lot of latency compared to the time serving those queries and some can also be done in parallel.