Undo optimization attempts for sqlite3

[DL6ER]

What does this implement/fix?

During the development of Pi-hole v6.0, we (blindly?) followed a blog post describing that increasing the number of allowed workers as well as changing the default location for temporary objects from always-on-disk to always-in-memory is key to increased performance without doing any real measurements on this - at least it did not make things slower.

Nothing unexpected showed up during the extended v6.0 beta period but now we have #2194 and friends describing a massively increased memory and CPU usage on devices that were always on the edge of being still feasible for Pi-hole: Using millions of lists on devices that merely have 256 MB RAM for the entire system.

This PR seeks to undo these optimization-attempts as more thorough performance measurements actually revealed that

• changing the default location for temporary objects from always-on-disk to always-in-memory had no positive effect because we also have HAVE_FDATASYNC and SQLITE_DEFAULT_SYNCHRONOUS. This means that even the temporary files we are writing may never actually hit the disk and still live in memory if and only if there is enough RAM available (it is the yellow memory in htop, also called "cached"), and
• increasing the number of allowed workers actually slightly lowers the performance of building the tree as multi-thread locking introduces so much overhead that the gain is lost and, actually, some extra bit of performance penalty is added. Creating an index is a task that is hard to parallelize and, hence, single-core performance is already close to the maximum

---

Related issue or feature (if applicable): Fixes #2194

Pull request in docs with documentation (if applicable): N/A

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• The code change is tested and works locally.
• I based my code and PRs against the repositories developmental branch.
• I signed off all commits. Pi-hole enforces the DCO for all contributions
• I signed all my commits. Pi-hole requires signatures to verify authorship
• I have read the above and my PR is ready for review.

[DL6ER]

Confirmed by OP in #2194 (comment)

[DL6ER]

After this PR has been merged, it's time for FTL v6.0.4

[XhmikosR]

It seems the default value for temp store is 1, are you sure that 0 is fine?

(Haven't been able to test this branch yet)

[yubiuser]

Default is 0 as per https://www.sqlite.org/pragma.html#pragma_temp_store

Add: but 1 according to https://www.sqlite.org/compile.html#temp_store

OK, this is really confusion: https://www.sqlite.org/tempfiles.html#tempstore

It seems the compile time option SQLITE_TEMP_STORE defaults to '1'

'Use files by default but allow the PRAGMA temp_store command to override'

But PRAGMA temp_store defaults to 0

Use either disk or memory storage for temporary files as determined by the SQLITE_TEMP_STORE compile-time parameter.

[XhmikosR]

Yeah, I came across the second reference, that's why I'm asking.

[XhmikosR]

Confirmed that this branch does behave a lot better:

  [✓] Building tree
  --> took 86.697 seconds
  [i] Number of gravity domains: 2705529 (2257418 unique domains)
  [i] Number of exact denied domains: 9
  [i] Number of regex denied filters: 2
  [i] Number of exact allowed domains: 10
  [i] Number of regex allowed filters: 0
  --> took 17.030 seconds
  [✓] Optimizing database
  --> took 18.726 seconds
  [✓] Swapping databases
  [✓] The old database remains available
  --> took 16.875 seconds
  [✓] Cleaning up stray matter
  --> took 0.304 seconds

  [✓] Done.

[DL6ER]

Thank you for the careful review, you are absolutely right about the 0/1. I fixed that now and force pushed it down to a single commit.

[yubiuser]

I guess this means this line can loose its PRAGME statement

https://github.com/pi-hole/pi-hole/blob/f207385269b273dfb7d0b89d3221b1f017a8fa16/gravity.sh#L96C59-L96C76

[XhmikosR]

pi-hole/pi-hole#6039