In our previous two articles, we’ve taken an in-depth look at the Salesforce platform’s application architecture and delved into its data layer. Now, let’s dissect an integral component of Salesforce’s data processing: query execution.
Understanding Query Execution
Most modern database systems utilize an optimizer to determine their query execution plans, considering relevant statistics about table and index data. However, this approach was designed for single-tenant applications and doesn’t adequately account for the data access characteristics of a user executing a query in a multi-tenant environment.
To provide the necessary statistics for determining optimal query execution, the Salesforce platform maintains statistics at the tenant group and user level for every org’s objects. These statistics represent the number of rows a particular query could potentially access.
(https://youtu.be/xEm-UbEidw8)
How Salesforce Adapts to Multi-tenant Environments
Salesforce’s statistics take into account org-specific object statistics, like the total number of rows owned by an org as a whole, as well as more granular statistics, such as the number of rows a user potentially has access to based on their permissions.
The query optimizer uses internal, security-related tables to determine a user’s access rights for objects and rows. Furthermore, the platform maintains other types of statistics for certain queries, like the cardinality of values in a picklist or the number of unique values in a field.
The Query Processing Cycle
When a request for data is received from sources such as an API call or a stored procedure, the Salesforce platform goes through a series of steps:
- Pre-query execution: The system considers the statistics mentioned above and several others to execute a set of pre-queries.
- Query optimization: Based on the results returned by these pre-queries, the system builds an optimal underlying database query for execution.
- Query execution: Finally, the system executes the query and returns the results back to the requester.
It’s important to reiterate that as an architect, the functionality discussed in this article is not something you can change. However, understanding how Salesforce handles query processing in multi-tenant environments can inform your decision-making process and provide clarity on certain topics covered in the Salesforce Well-Architected Framework.
This article only provides a high-level overview of query processing in Salesforce. To dig deeper, check out the Platform Multi-tenant Architecture document and the Salesforce Well-Architected Framework available on the Salesforce Architects website.
In Retrospect: Navigating Salesforce’s Depths
Over the course of this three-part series, we embarked on a comprehensive journey through the layered intricacies of the Salesforce platform. We began by demystifying the foundational concept of Salesforce’s Multi-tenant Architecture, followed by an enlightening exploration into the roles of Metadata and Virtual Application Components. Concluding with the mechanics of Query Processing in Multi-tenant Environments, this series has provided a holistic view of Salesforce’s robust and sophisticated architecture. As with any expansive platform, understanding its underpinnings is crucial for optimal utilization.
We hope that this series has equipped you with enriched insights, enabling you to leverage Salesforce’s capabilities more effectively. Whether you’re an architect, a developer, or an enthusiast, thank you for joining us on this enlightening voyage into the heart of Salesforce.
