3 ms·

Right, but they are not the official defaults. If you are changing the official defaults, then you might as well do it in a more principled way. If you are goi

by ratorx 2y ago

Right, but they are not the official defaults. If you are changing the official defaults, then you might as well do it in a more principled way. If you are going to need to optimise with performance metrics anyway, then why not stick to just the official defaults (unless the official defaults are non-functional, is that the case?) I think anyone who is reading a blog post on “better defaults” is front loading some of the optimisation, so you could let them make a principled choice straight away for marginal extra cost.

nemothekid 2y ago
A lot of these aren’t defaults because of backwards compatibility. IMO there is no reason to not use WAL mode, but it’s not default because it came later
- bruce511 2y ago
  As long as all the processes are on the same machine the wal mode is a good idea. It's not good in the case where multiple machines are sharing the same database. Like say if you had a shared settings file which allowed multiple VMs to be set in one place. Obviously the same-machine situation is the most common. But you asked for a reason for when wal is not appropriate.
- prirun 2y ago
  There is a list of 6 disadvantages of WAL mode on the SQLite site: https://www.sqlite.org/wal.html https://www.sqlite.org/wal.html
TheRealPomax 2y ago
There is some principle here: these are more sensible defaults (but still only defaults) for a very different purpose when compared to the defaults that make sense for "generic SQLite use" that has to keep those set to something that works across all versions. Having different, domain-specific defaults based on an assumption of "you're setting up a new project using the current version of SQLite" makes a whole lot of sense.
antisthenes 2y ago
> If you are going to need to optimise with performance metrics anyway, then why not stick to just the official defaults (unless the official defaults are non-functional, is that the case?) Well, why don't you do the research and tell us? In my 10-15 years of dealing with official defaults of many programs is that they do work, but in 90% of cases they are overly-conservative.

by ratorx 2y ago

nemothekid 2y ago

A lot of these aren’t defaults because of backwards compatibility. IMO there is no reason to not use WAL mode, but it’s not default because it came later

bruce511 2y ago
As long as all the processes are on the same machine the wal mode is a good idea. It's not good in the case where multiple machines are sharing the same database. Like say if you had a shared settings file which allowed multiple VMs to be set in one place. Obviously the same-machine situation is the most common. But you asked for a reason for when wal is not appropriate.
prirun 2y ago
There is a list of 6 disadvantages of WAL mode on the SQLite site: https://www.sqlite.org/wal.html https://www.sqlite.org/wal.html

TheRealPomax 2y ago

There is some principle here: these are more sensible defaults (but still only defaults) for a very different purpose when compared to the defaults that make sense for "generic SQLite use" that has to keep those set to something that works across all versions. Having different, domain-specific defaults based on an assumption of "you're setting up a new project using the current version of SQLite" makes a whole lot of sense.

antisthenes 2y ago

> If you are going to need to optimise with performance metrics anyway, then why not stick to just the official defaults (unless the official defaults are non-functional, is that the case?) Well, why don't you do the research and tell us? In my 10-15 years of dealing with official defaults of many programs is that they do work, but in 90% of cases they are overly-conservative.