@Max Ross I suppose if you split it up that way where writes would actually cost more since it would count index writes too, then that would still encourage efficiency. I've spent effort reducing the number of indexes on my entities, and didn't want that effort to be wasted.
On May 11, 9:22 am, "Max Ross (Google)" <max.r...@gmail.com> wrote: > We're still sorting out the details, but we will most likely be charging for > entity reads, entity writes, and index writes. This is actually pretty > similar to what we do today, but we think the units are easier to understand > than cpu. > > Under this proposed model, multiget/multiput are a single api call but the > cost will be determined by the number of entities you are fetching or the > number of entities and indexes you are writing with that single api call. > > Question for Spines: > Why do you feel that charging the same amount for reads and writes > discourages efficiency? I think the correct incentives are in place under > the proposed model: For writes, if you have fewer indices on your entity > your writes are cheaper. For reads, the cost is directly tied to how much > data you pull back. > > Hope this helps, > Max -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
