11–20 of 84 posts
Earlier quoted context omitted.
The association between vulgarity and propriety (and class distinctions) sort of ruins that word, particularly in the english speaking west. I wonder if that's as big of a problem in the romance languages (which all treat left/right the same way - left = bad, right = good)
Indeed: are you sinister or dexterous?
- direction
- straight ahead
- civics
- propriety
[flagged]
Earlier quoted context omitted.
Note that, in the abstract, “vulgar” means “common” (as in “vulgar latin”). Indeed, its negative connotations come from that same sense: “common” people are unrefined.
The association between vulgarity and propriety (and class distinctions) sort of ruins that word, particularly in the english speaking west. I wonder if that's as big of a problem in the romance languages (which all treat left/right the same way - left = bad, right = good)
[flagged]
I realized after a few years of doing it that my strategy for keeping Wikis useful is to treat them as B-Trees. When the landing page gets too full/too many outgoing links, I start pushing links and paragraphs down into the child pages, to leave space for a fair share of timely links and on-boarding docs. Similar and older links get pushed down into the sibling that best represents the topic. Then if the destination…
Do you have a recommendation for Wiki software you like to use? My team is in need of an internal knowledge base, and I like the structure of wikis. Most of the SaaS products I've tried or looked at are a bit too shiny/fancy and don't seem to match my mental model of how a wiki-style knowledge base should work.
But if you were shopping for one, from the standpoint of keeping the docs working being able see missing pages and see incoming links to a page are both pretty helpful. I kinda miss the latter.
Earlier quoted context omitted.
The association between vulgarity and propriety (and class distinctions) sort of ruins that word, particularly in the english speaking west. I wonder if that's as big of a problem in the romance languages (which all treat left/right the same way - left = bad, right = good)
Indeed: are you sinister or dexterous?
The challenging part was evicting the expired keys from the BTree+ where the inserted keys would have TTL therefore we decided to fuse only one level branch and within the first sibling leaf nodes as it would be expensive if we perform clean up all the way up which would cause high lock contention and slow things down substantially specially when keys get inserted/deleted/updated.
Also we had to do sharding on top of the BTree+ to speed things up and reduce the high lock contention, that way we know what shard the the keys belong to and we lock the branch before performing any CUD, That way we can perform high concurrent operations on multiple shards/branches.
The clean up process might have some caveat and the Btree+ ends up unbalanced. We had to provide rebuild indexing feature so that would fix all the gaps if necessary to avoid extra clean up operations.
Again Thanks for the visuals.
For one, it's enormous. Now you have to copy that 128bit int to every side of the relation.
Two, in most cases it's completely random. Unless you had the forethought to use something other than UUIDv4 (gen_random_uuid). So now you just have a bunch of humongous random numbers clogging up your indexes and duplicated everywhere for no good reason.
Use regular bigserial (64bit) PKs for internal table relations and UUIDs (128bit) for application-level identifiers and natural keys. Your database will be very happy!
This is why you should _never_ make your UUID column the primary key. For one, it's enormous. Now you have to copy that 128bit int to every side of the relation. Two, in most cases it's completely random. Unless you had the forethought to use something other than UUIDv4 (gen_random_uuid). So now you just have a bunch of humongous random numbers clogging up your indexes and duplicated everywhere for no good reason. Us…