Not a full R
article, but a quick note demonstrating by example the advantage of being able to collect many expressions and pack them into a single extend_se()
node.
This example may seem extreme or unnatural. However we have seen once you expose a system to enough users you see a lot more extreme use cases than you would at first expect. We have actually seen large tens of columns added to a mart in a large irregular block (so not the same transform for each columns) by building up long pipelines, so this simplified example is in fact relevant to production deployments.
First set up our packages, database connection, and remote table.
1 |
|
1 |
|
1 |
|
1 |
|
rquery
torture function: add 100 columns to a 1000000 row table.
1 |
|
1 |
|
1 |
|
1 |
|
The row-selection step is to cut down on the in-memory cost of bringing the result back to R
. Obviously we could optimize the example away by pivoting the filter to earlier in the example pipeline. We ask the reader to take this example as a stand-in for a more complicated (though nasty) real-world example where such optimizations are not available.
Same torture for dplyr
.
1 |
|
1 |
|
1 |
|
We can also collect expressions efficiently using seplyr
(seplyr
is a thin wrapper over dplyr
, so seplyr
‘s method mutate_se()
is essentially instructions how to do the same thing using rlang
).
1 |
|
1 |
|
1 |
|
Time the functions. Timing is not going to be certain given issues such as cluster state and query caching.
1 |
|
Present the results.
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
rquery
is about 2.5 times faster than dplyr
for this task at this scale for this data implementation and configuration (we have also seen an over 8 times difference for this example on PostgreSQL
).
1 |
|
Original code here.
Like this:
Like Loading…
Related