11–20 of 61 posts
Just an endless sequence of misbehavior and we’re waving it off as rows work good for specific lookups but columns for aggregations, yet here it is all the other stuff that is unreasonably slow.
Another example of row based dbs somehow being insanely slow compared to column based. Just an endless sequence of misbehavior and we’re waving it off as rows work good for specific lookups but columns for aggregations, yet here it is all the other stuff that is unreasonably slow.
It's an example of old things being new again maybe. Or reinventing the wheel because the wheel wasn't known to them.
Yes I know, nobody wants to pay that tax or make that guy richer, but databases like Oracle have had JPPD for a long time. It's just something the database does and the optimizer chooses whether to do it or not depending on whether it's the best thing to do or not.
Another example of row based dbs somehow being insanely slow compared to column based. Just an endless sequence of misbehavior and we’re waving it off as rows work good for specific lookups but columns for aggregations, yet here it is all the other stuff that is unreasonably slow.
“We filtered first instead of reading an entire table from disk and performing a lookup”
Where both OLAP and OLTP dbms would benefit.
To your point, it’s clear certain workloads lend themselves to OLAP and columnar storage much better, but “an endless sequence of misbehavior” seems a bit harsh .
Straddled joins were still a bottleneck in Readyset even after switching to hash joins. By integrating Index Condition Pushdown into the execution path, we eliminated the inefficiency and achieved up to 450× speedups.
Why downvote?
It could just be that they translated from their original language to English and got that as a byproduct. Many such cases.
Another example of row based dbs somehow being insanely slow compared to column based. Just an endless sequence of misbehavior and we’re waving it off as rows work good for specific lookups but columns for aggregations, yet here it is all the other stuff that is unreasonably slow.
It's an example. But not of that. It's an example of old things being new again maybe. Or reinventing the wheel because the wheel wasn't known to them. Yes I know, nobody wants to pay that tax or make that guy richer, but databases like Oracle have had JPPD for a long time. It's just something the database does and the optimizer chooses whether to do it or not depending on whether it's the best thing to do or not.
[1] https://www.cockroachlabs.com/blog/building-cost-based-sql-o...
Push down filters to read the least data possible.
Or, know your data and be able to tell the query engine which kind of join strategy you would like (hash vs push down)
Maybe it's not obvious initially, but in retrospect, this handling of joins feels like the obvious way to handle it. Push down filters to read the least data possible. Or, know your data and be able to tell the query engine which kind of join strategy you would like (hash vs push down)
Maybe it's not obvious initially, but in retrospect, this handling of joins feels like the obvious way to handle it. Push down filters to read the least data possible. Or, know your data and be able to tell the query engine which kind of join strategy you would like (hash vs push down)
I read their website landing page but it’s still kinda confusing — what exactly is readyset? It all sounds like it’s a cache you can set up in front of MySQL/postgres. But then this article is talking about implementing joins which is what the database itself would do, not a cache. But then the blurbs talk about it like it’s a “CDN for your database” that brings your data to the edge. What the heck is it?!