Making Postgres slower(byteofdev.com) |
Making Postgres slower(byteofdev.com) |
Maybe it could be like O’Reilly, except the covers could have shittily-drawn fantasy animals, e.g. a 7-year-old’s drawing of a unicorn with a head on each side of its body both talking on their AirPods giving away their money to scammers, making PowerPoint slides, eating too much, doing hard drugs, live-streaming on Facebook, and standing on the railroad tracks with a train in the distance.
Source: https://medium.com/butwhatfor/suppose-i-wanted-to-kill-a-lot...
If you are ever going to get to grips with optimizing something, why not do the opposite first or as a foil?
How often do you really fenangle your database (or other system) properly? Are your performance enhancements really based on science or cargo culting or something else?
Plus, those sorts of artificial limitations can be really helpful in finding where your systems bottleneck and what are the main optimizations that you should do (for example, I've seen N+1 problem sneak past because at the time the performance was good enough but once there was enough data it crumbled).
This is a super-common problem I've had to help with many times. It generally happens with teams working on single-tenant (or single-database-tenant) products, and basically always comes back to the dev team working on a database with hundreds of things, and there's a handful of customers using 10,000+ things when it starts getting slow.
You acquire a bunch of small customers and everything is great, and it can months later before you really start to see performance impact. And often with these types of problems it just gradually slows down until finally the system hits a wall where the DB can no longer compensate and suddenly performance tanks. "It must be caused by something we just added, but it's weird, because this problem is in a totally different part of the system."
The data access interface was simple enough, that it allowed interface layering allowing for different backends, encryption, etc. to be very flexible.
I had adapters for SQLite (default), MS-SQL, PostgreSQL, Redis, Cassandra and AWS DynamoDB. It was deployed for apps that went from embedded, to integrated with our applications, and external applications on internal and external infrastructures.
The only disappointing thing is that I wasn't allowed to open-source/release the application. The concern is it would be a security risk if anyone knew how the application worked. I still disagree with this decision. It was a bit simpler, and more flexible than "Identity Server" in use, but it served the needs of a lot of applications where an existing identity provider (IS, Octa, AD Auth, etc) wasn't already in place. Most of the apps I worked on at that company had used JWT allowing for somewhat flexible configurations of RSA signed providers... integration usually consisted of a bridge service for authentication going from the client's provider to an app targeted JWT. This kept integrations separate.
Sorry for veering off a bit.
Uh, that's the classic security through obscurity (STO) defense on the face of it but it sounds like a cop-out to not open source it. If one desires not to open something that's fine, but if they misrepresented the reason for doing so would be bullshit.
A decent sized SaaS-like with usage simulation, and a postgres/rabbit setup that is merely fine. A place to check if your debugging tooling/strategy is upt to snuff.
In the first story in the book you learn how to do platoon level tactics badly( and lose most of your men )
In each subsequent story, a few tactical parameters are tweaked and the story is recounted again, with improved results.
The same approach is used in newer tactical books like Musicians of Mars 2.
The first Team Badger story in Musicians is very similar to the first story in Duffer's Drift, allowing for changes in location, equipment and techniques..
Warning: PDFs below:
The Defence of Duffer's Drift https://www.armyupress.army.mil/Portals/7/combat-studies-ins...
Musicians of Mars 2 https://api.army.mil/e2/c/downloads/2023/01/19/5a01ae1c/16-1...
"The lingering sulfur odor of gunpowder, mixed in the haze of the dust and smoke of battle, dominated the senses of CPT Fred Morris, commander of Team Badger. He sat amid the wreckage of what used to be some of the world’s finest combat machines, M1A2 Abrams tanks and M2A3 Bradley fighting vehicles.
Now most of his company’s tanks and Brads were mere smoking hulks, emanating the distinct smell of burning electronics to add another element to the senses of the dismal scene before him.
He sat, quietly reflecting on the sequence of events that led to the destruction of his beloved team. His mind raced as he recounted how the enemy force, so much more formidable than he had expected, employed assets, capabilities, and tactics that he had not taken into account. At the same time, he wondered why he was unable to bring to bear his own extensive combat power to earn decisive victory. He had felt so ready, so confident, and believed that his team had prepared so diligently.
Yet, still they had been defeated so soundly. How could that be? LTC Joe Milner, the task force commander, had given Team Badger the task to defend the center of the task force main battle area (MBA) in an area defense to destroy the attacking enemy motorized rifle brigade. Specifically, CPT Morris and Team Badger were to defend against the enemy’s main effort motorized rifle battalion in Battle Position (BP) Badger, along the enemy’s most likely avenue of approach.
That motorized rifle battalion plowed through Team Badger as if it were not even there."
If you wanted to run PostgreSQL in a lower memory device, such as a lower end RPi, then you might want specific features tuned down based on your real workloads. Especially if you are considering say SQLite, but aren't sure how it will perform vs. putting say half the system's resources to PG.
I think if someone achieved 42,000:1 they'd be accused of sorcery and burned at the stake.
I found that we were hit by a bug that was fixed 6 years before I discovered it (https://sqlite.org/src/info/6f2222d550f5b0ee7ed). Sqlite's query planner assumed that a field with a not null constraint can never be null, which isn't the case for the right hand table in a left join.
Also, this contemporary homage published recently on a British military blog: https://wavellroom.com/2025/07/25/defence-baltic-bridge-drea...
As I understood: Missile uses gyros and accelerometers to figure out how far it flew already towards the target. This is not 100% accurate.
So it additionally uses terrain mapping to figure out how it looks down there. Compare ground (am I flying above a slope?) to its internal maps and it can figure out where it is and adjust path if off course.
So it figured out the position by knowing that the position is most likely not the position where it's supposed to be.
AFAIK, yes, that's what it actually was (or the basic sentiment actually came from). It was some part of training video in the US army/navy (don't know exactly), but the actual story or origin remains a bit unclear. At least my search within the web did not yield any (assumingly) valid source. I think at some point it just got to "it is what it is now" because it is a very, very complicated way to explain this stuff.