undefined | Better HN

Skip to content

Top Best Ask Show New Jobs

0 pointslobster_johnson11y ago0 comments

It wasn't using an index, but then Postgres wasn't, either. I don't think aggregating via B-tree index is a good idea; aggregation is inherently suited to sequential access. An index is useful only when the selectivity is very low.

0 comments

4 comments · 1 top-level

SamReidHughes11y ago· 3 in thread

If you wrote your query with group and count, with no index, then there would be problems with the performance. RethinkDB generally does not do query optimization, except in specific ways (mostly about distributing where the query is run), unless that's changed very recently. You can write that query so that it executes with appropriate memory usage with a map and reduce operation.

lobster_johnsonOP11y ago

Do you think map/reduce would result in performance near what I get from Postgres?

SamReidHughes11y ago

You would get the same behavior that Postgres's would be in terms of how data is traversed and aggregated -- that is, not by building a bunch of groups and counting them after the fact. I do think RethinkDB ought to be able to apply aggregations to group queries on the fly though... I'm not really up to date on that.

Postgres will still have better numbers, I'm sure. It has a schema for starters.

rspeer11y ago

I haven't used RethinkDB, but I would assume the answer is no. Choosing to use map/reduce is basically a declaration that performance is your lowest priority.

j / k navigate · click thread line to collapse