SQL functions often get inlined into the calling query Views get flattened into the query that uses the view The same is true of things like EXISTS and NOT EXISTS queries. The subquery can, and often is, flattened into a join on the outer table. Terms in the subquery can be pulled up to the outer query so their execution is done as part of the outer query, not where you wrote them in the subquery Terms outside a subquery can get pushed down into the subquery so they execute as part of the subquery not where you wrote them in the outer query PostgreSQL will heavily transform queries while retaining the exact same effects, in order to make them run faster while not changing the results. This is important if you call functions with side-effects. There's no guarantee PostgreSQL will actually execute parts of the query at all. Often in reality the subquery gets executed kind-of in the middle, or interleaved with the outer query. Subqueries can be executed before or after the query that contains them, depending on what's fastest, so long as the subquery is executed before the outer query actually needs the information. The order in which joins are written is also ignored up to the configured join_collapse_limit if there are more joins than that, it'll execute them in the order they're written. PostgreSQL doesn't care at all about the order of entries in a WHERE clause, and chooses indexes and execution order based on cost and selectivity estimation alone. To elaborate on answer: PostgreSQL doesn't care what order you write things in
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |