When I getting all fields is it applied to general performance or not? or no need too much for care about it.

My query looks like that:

Map<String, Schema.SObjectField> fieldsMap = MyObject__c.sObjectType.getDescribe().fields.getMap();
String fields = String.join(new List<String>(fieldsMap.keySet()), ',');
List<String> fillers = new List<String>{fields};
String query = 'SELECT {0} FROM MyObject__c WHERE Id = :someVar';
String formattedQuery = String.format(query, fillers);


Is it better performance if my query something like that:

String query = 'SELECT Id, Name, SomeField__c, OtherOne__c, MaybeMore__c FROM MyObject__c WHERE Id = :someVar';  
  • 2
    Since it is only 500 fields on sObject, that should not be a problem for SOQL query generation. You will hit max query length request earlier rather then get performance issue with your code. I have same snippet working fne for 2 years in managed package for multiple sObjects with approx 500 fields – kurunve Dec 21 '17 at 11:01

Yes, it will affect performance and also heap size, so I would only get the fields that you need. This is one of the reasons SalesForce does not have a SELECT * function. The problem with your code, would be when users begin adding more and more fields to the object, it will slow your query results, but could also cause you to hit further governor limits.

It's worth looking at this SalesForce Article that has further links to help understand query performance. I would also consider testing your queries in the Query Plan Tool.

Another good read is the SalesForce Working with Very Large SOQL queries article- there are some good examples and also some good ideas around best practices.


Where you have performance concerns it is worth dong some simple tests to see if those concerns are valid or not. This code run via "Execute Anonymous":

Long t1 = System.currentTimeMillis();
Contact[] cs = [select Id from Contact limit 100];
Long t2 = System.currentTimeMillis();
System.debug(t2 - t1);

returns values in the range of 3 to 6 milliseconds.

The query call involves a request to a different process (and usually machine), then the database has to do the work of pulling the data from disk on the first call then from memory in subsequent calls (from cached pages), then the response is returned. This is way more time consuming than building strings in code: the performance of the solution is dominated by how many "expensive" requests are made with most Apex code being insignificant.

In your case, I would use the Apex code option that is simplest to understand and so easiest to maintain.

(Easy maintenance is also a factor with using the select * approach. Anyone who has worked in Salesforce for a while will have experienced "SObject row was retrieved via SOQL without querying the requested field" exceptions where a minor change in one place requires the fixing of a query in another place. So select * can be appropriate.)

  • thanks. This is a good suggestion! to figure out actual difference – HappyCoder888 Dec 21 '17 at 12:09
  • 1
    Using "select *" type behavior can cause unexpected crashes. Easy maintenance is not a good reason; it can arguably increase maintenance. I have a PoC that demonstrates this. – sfdcfox Dec 21 '17 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.