The postgres query optimizer will try to minimize the number of pages read from disk (and the number of intermediate pages written to disk). Benchmarking the query optimizer by making the shared buffers large enough to hold all the data therefore seems wrong, as you're then measuring the speed of the query optimizer and the join processor, instead of the quality of the generated query plans. It would not surprise me if the generated plans for these versions are actually all the same and this is only measuring execution speed.
A government's primary purpose is to act on behalf of its constituents, and if these daytrippers are substantially detrimental to Amsterdam's livability, they should be discouraged from going there.
Or, to put it in more financial terms, the cost of compensating for the negative effects of these tourists might be much higher than the tax revenue they bring in.
Fly postgres is not managed postgres, it's cli sugar over a normal fly app, which the [docs](https://fly.io/docs/postgres/) make quite clear. Their docs also make clear that if you run postgres in a single-instance configuration, if the hardware it's running on has problems, you database will go down.
I believe the underlying reason that precludes failing over to a different host machine, is that fly volumes are slices of host-attached nvme drives. If the host goes down, these can't be migrated. I _think_ instances without attached volumes will fail-over to a different host.
Of course, that's not ideal, and maybe their CLI should also warn about this loudly when creating the cluster.
I would substantially nuance most of what you say. I really like vim and use it almost exclusively, but it is not necessarily the "only" way, or even necessarily the "best" way to do things. If the vim grammar clicks for you, great, by all means use it. There are people for whom it doesn't click, and that's fine too. I do encourage everyone to try it for a bit.
I also would not say learning vim makes you a better programmer or a better writer. It makes inputting and changing text easier and faster, but that's not what programming or writing is about.
I agree that the vim grammar is nice, but the bigger thing that differentiates editing text in vim versus other editors is its modality. And it is the modality that allows it to have a grammar in the first place. And that grammar does break down in places, just look at every keybind starting with g.
So yes, try vim, because it is pretty great. But if it doesn't work for you, move on to something that does.
The problem of dangerous interactions between drivers and cyclists is much smaller here in the Netherlands, mainly due to two reasons.
The first reason is the infrastructure, both visible and invisible. Separated bicycle lanes are commonplace and in the few places where they intersect with car traffic, care is taken to make crossing safe and comfortable. This visible infrastructure is complemented by the concept of "Hoofdnetten", where the default routes to some place for different modes of transportation coincide for the least amount of time/space. For example, going somewhere by bike might take you through a residential neighborhood with barely any traffic, which is also slowed by speed bumps and narrowed streets, whereas buses will use a bus lane taking a slightly longer route, and car traffic has to go all the way around.
The second reason is that here, everyone is a cyclist. Going for groceries? Five minute bike ride, much easier and quicker than going by car. Kids cycle to school alone from a young age. Going out for drinks? Bike.
Because everyone is a cyclist and there are cyclists everywhere, cyclists are equal participants in traffic and are treated with care and respect.
It depends. For operations or aggregates on a single field, it improves cache locality, whereas if operations act on all, or most, fields of the struct, it hurts cache locality. The exact same tradeoff differentiates OLTP (transactional/row stored) databases and OLAP (analytics/column stored) databases.