Cost of projection query?

108 views
Skip to first unread message

Susan Lin

unread,
Feb 4, 2016, 6:36:39 PM2/4/16
to Google App Engine
I would like to confirm the cost of a projection query. According to https://cloud.google.com/appengine/pricing the cost of a project query is 1 read operation while a a normal query getting the whole entity is 1 read + 1 read per entity retrieved. 

If I have entities in this structure:

MyEntity
-ID
-Name
-Birthday

If I select do a projection query to get retrieve the ID and Name of everyone who's birthday is greater than a some date lets say Jan 1st 2000. If there are 100 entities which match does the return only count as 1 read to get all 100 entities back? If this is the case then say I also want to retrieve the birthday property, but don't wan't to select all the properties to avoid a query which gets the whole entity then why not then add a dummy property that has no use to the entities so then you can still select all the properties I need (ID,Name, and Birthday) and still only use 1 read operation. 

If I did a query to select all the properties of a user who's birthday is greater than a some date lets say Jan 1st 2000. If there are 100 entities which match does the return will costs be 1 + 100 read operations? 

Cheers

Adam (Cloud Platform Support)

unread,
Feb 9, 2016, 7:15:07 PM2/9/16
to Google App Engine
There are limitations to what you can do with projection queries (see Limitations on projections). Notably, all properties in a projection query require an index which can incur other costs such as increased number of write ops. This also means you cannot include long byte strings or text strings in a projection.

With that being said, projection queries require a far fewer number of read ops compared to normal queries and are good to use when it makes sense to do so. On a specific test I've seen around 0.03 million ops for a batch of regular queries where the same number of projection queries is too small to register in the console, so a 1:100 difference sounds about right.
Reply all
Reply to author
Forward
0 new messages