Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why return the primary key when performing a secondary index query instead of the whole record? This seems like it would add an extra round-trip. Would it be possible add a flag to return the whole record?


Excellent suggestion, and something we're already considering for a future release.

Our current reasoning is that if you are only pulling back one or two objects, then an extra round trip probably isn't that bad. If you're pulling back many objects for processing, then you might be better off feeding the query results into a MapReduce job so that it runs in parallel across the cluster.


You can use the index as input into a map reduce query which will bulk load the documents across the cluster.

You can then filter, transform, sort, limit, etc the documents from within the map reduce query.

What I'd like to see is the ability to use the index as the input and then use key filters to enable the ability to pre-filter the map-reduce query using meaningful keys. This maybe possible now, I haven't tried it.


Seems similar in thought to DNS's additional section, where a DNS server can say `hey, here is your answer, and oh by the way, you might want this other information too'. Example use case: if you get a CNAME back, then you will probably want the associated A record as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: