The "preview" and "code" buttons in the components break the "alt+arrow" bindings to go back to the previous page. Instead it just alternates between "preview" and "code".
I have to say, it is _extremely_ impressive when a tiktok I watched reminds me of some other tiktok, so I go and search for a very loose description of the tiktok, and the first result is 95% of the time what I wanted to find.
I don't think any single other platform has as good a search feature as TikTok does.
oh wow, you're really lucky. around my friend groups who use tiktok, the main complaint is how bad the search is. unfortunately for us, getting a specific video is almost impossible =(
Thats super interesting (I deleted Tiktok because it was too addicting!), but this is a common complaint about Instagram is that it feels impossible to find a reel based on keywords.
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.
reply