I never got to test this, but I always wanted to explore in postgres using table partitions to store soft deleted items in a different drive as a kind of archived storage.
I'm pretty sure it is possible, and it might even yield some performance improvements.
That way you wouldn't have to worry about deleted items impacting performance too much.
It's definitely an interesting approach but the problem is now you have to change all your queries and undeleting get more complicated. There are strong trade-offs with almost all the approaches I've heard of.
With partitioning? No you don't. It gets a bit messy if you also want to partition a table by other values (like tenant id or something), since then you probably need to get into using table inheritance instead of the easier declarative partitioning - but either technique just gives you a single effective table to query.
If you are updating the parent table and the partition key is correctly defined, then an update that puts a row in a different partition is translated into a delete on the original child table and an insert on the new child table, since v11 IIRC. But this can lead to some weird results if you're using multiple inheritance so, well, don't.
I believe they were just pointing out that Postgres doesn't do in-place updates, so every update (with or without partitions) is a write followed by marking the previous tuple deleted so it can get vacuumed.
It's an important distinction, just like it's important to know that "const foo *" doesn't mean the foo is constant, just that YOU cannot change it.
Just because you build a unique_ptr from a raw pointer it doesn't mean that it is now magically owned by the object. You also have to ensure that no other place already did that, which unique_ptr simply cannot enforce.
No one is doing 1x10 key presses. That's now how humans process information. You repeatedly press a key one time until what you see on screen is what you want. The further away you are the faster you do it.
I've tried so many times to make it work, I've really tried. But it just ends up being faster to spam j a couple of times instead of having to think about how many times I want to move, then type it, then be wrong, then try again...
For larger distances you wouldn't even see the text in the screen, so you don't even know how much to jump. In this situation I just spam ctrl+d, then tweak with j.
You can jump to line numbers without them being relative. Enter the line number and hit G or gg. Out of the box behavior, and you don't need to obscure the real line numbers that way.
Right, but obviously people in this comment thread are trying to use relative jumps (which I also have a strong preference for), but seem to be under the impression you must guess the distance: you do not.
Typing 5j, where the number "5ish" was already loaded into your brain by looking at the distance, is 100x better than typing 384g, where 384 is an effectively meaningless number and will change momentarily anyway.
Fwiw, relative line numbers doesn't obscure the "real line numbers" in any meaningful way. First of all, real line numbers aren't used for anything except external references into the file, which you can still navigate to perfectly fine using G or g. Also, relative line numbers show your current line's real line number at all times.
There have been exactly zero times I've regretted having relative line numbers on and it's not default behavior, that's why it's useful to point out here.
You've heard of infrastructure as code, now presenting air strikes as code!
Need a new secret offensive operation? Create a new JSON file with the coordinates, make a merge request and get Commander approval, merge it, and our new proprietary GitHub action runner will deploy a drone in seconds!
This is far too simple. The correct way is to generate an NFT that's a screenshot from Google Maps of where you'd like to hit, and a blockchain-watching AI will spot it, figure out where you probably mean and send the coordinates to the fire control system.
I can be in a room looking at something with my eyeballs and listening with my ears perfectly legally... But it would not be legal if I replaced myself with a humanoid mannequin with a video camera for a head.
You can even write down what you are looking at and listening to, although in some cases, dissemination of, e.g. verbatim copies in your writing could be considered copying.
But it is automatically copying if you use a copier.
I'm pretty sure it is possible, and it might even yield some performance improvements.
That way you wouldn't have to worry about deleted items impacting performance too much.
reply