From 23da400fbc6909660c7fd6442d067c8c8db8ae59 Mon Sep 17 00:00:00 2001 From: Tobias Pfeiffer Date: Mon, 7 Oct 2024 21:21:09 +0200 Subject: [PATCH] Include a preload joins vs. no joins discussion in the preload docs (#4517) --- lib/ecto/query.ex | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/lib/ecto/query.ex b/lib/ecto/query.ex index bd933da2bb..4168c49d1c 100644 --- a/lib/ecto/query.ex +++ b/lib/ecto/query.ex @@ -2667,6 +2667,30 @@ defmodule Ecto.Query do where: l.inserted_at > c.updated_at, preload: [:author, comments: {c, likes: l}] + ## Choosing between preloading with joins vs. separate queries + + Deciding between preloading associations via joins, a single large + query, (`preload: [comments: c]`) or separate smaller queries + (`preload: [:comments]`) depends on the specific use case. + Here are some factors to guide your decision: + + * **Joins reduce database round trips:** By fetching data in a single + query, joins can minimize database round trips, potentially reducing + overall latency. + * **Potential for data duplication:** Joins may lead to duplicated + data in the result set, which requires more processing by Ecto + and consumes more bandwidth when transmitting the results. + * **Parallelism with separate queries:** When using separate queries + outside of a transaction, Ecto can parallelize the preload queries, + which can speed up the overall operation. + + In general, a good default is to only use joins in preloads if you're + already joining the associations in the main query. For example, + in the last query in the section above, comments and likes are already + joined, so they are included in the preload. + However, the author is not joined in the main query, so it is preloaded + via a separate query. + ## Preload queries Preload also allows queries to be given, allowing you to filter or