|
4 | 4 | [](https://opensource.org/licenses/MIT) |
5 | 5 | [](https://coveralls.io/github/ash-project/ash_postgres?branch=master) |
6 | 6 | [](https://hex.pm/packages/ash_postgres) |
7 | | - |
8 | | -#TODO |
9 | | - |
10 | | -##Configuration |
11 | | - |
12 | | -- Need to figure out how to only fetch config one time in the configuration of the repo. |
13 | | - Right now, we are calling the`installed_extensions()` function in both`supervisor` and |
14 | | -`runtime` but that could mean checking the system environment variables every time (is that bad?) |
15 | | -- Figure out heuristics for when to left join/right join (alternatively, make it configurable via the query language) |
16 | | - For instance, if a relationship has a non-nil predicate applied to it in all`ors` or a single`and` then we should |
17 | | - be able to inner join. |
18 | | - I have learned from experience that no single approach here |
19 | | - will be a one-size-fits-all. We need to either use complexity metrics, |
20 | | - hints from the interface, or some other heuristic to do our best to |
21 | | - make queries perform well. For now, I'm just choosing the most naive approach |
22 | | - possible: left join to relationships that appear in`or` conditions, inner |
23 | | - join to conditions that are constant the query (dont do this yet, but it will be a good optimization) |
24 | | - Realistically, in my experience, joins don't actually scale very well, especially |
25 | | - when calculated attributes are added. |