> literally save like 20 seconds in some cases because 1 HUGE query becomes 8 straightforward ones with maximum index usage.
I don’t understand how splitting a query up would have any relationship to index utilization; the planner should trivially pick up on it?
Also are you sure you’re not solving a different problem[0]? Doing joins manually being faster doesn’t smell right, except in the case of data duplication increasing total resultset size substantially
Like the cost of increased network load from not filtering through the join should outweigh anything else in the equation
> This is because taking up 100% of the CPU effectively captures 100% of RAM
Isn’t that only true though specifically at 100% CPU utilization?
If it were at 90% CPU, then you have no RAM capture, and then you can’t say anything about whether 80 or 800MB should be taken; it’s only a freebie if and only if literally no other program can do work on the machine.
I don’t see how you can map X% CPU utilization to Y% RAM capture.
Like a program could be network heavy, CPU light and mmaps a large file? Or streaming a file from disk with a constant memory allocation, but doing heavy nonstop CPU work.
The CPU / RAM capture ratio would be wildly different; the ideal for your program, while other competing programs of unknown behaviors exist, I don’t see any way for hotspot to approximate
> Isn’t that only true though specifically at 100% CPU utilization?
No. Because any RAM access requires CPU, using up any CPU effectively captures some ability to use RAM.
> I don’t see how you can map X% CPU utilization to Y% RAM capture.
You're right that there isn't a fixed formula, but the most efficient balance can have a narrow range, because CPU and RAM are typically sold as a package with a rather narrow RAM/core ratio (usually between 0.5 and 4GB, where the lower end is usually when you have slow cores). This is also because of the intrinsic relationship of RAM and CPU.
> Like a program could be network heavy, CPU light and mmaps a large file? Or streaming a file from disk with a constant memory allocation, but doing heavy nonstop CPU work.
A program that is very CPU light can't make use of a lot of physical RAM at any one time (again, because using RAM requires CPU). Once exception is caching, but memory access patterns for caching are easily detectable, and you can (and Java does) offer a different balance for them. I covered that in my talk, which will be eventually published on YouTube.
Depending on your access patterns, maybe you could have a hash table mapping entities ids to indexes in your SoA. Perhaps that's viable if looking up a single entity is not typical to your use case?
> Which leads to my theory… I feel like Bevy could be implemented on top of an in-memory DuckDB and get away with it
It’s a good abstraction layer, and a fundamentally good/effecient model of organization and data management. It’s a horrible language, has a meaningless standards doc, some of the worst debugging tooling of modern system and generally any tooling outside of the RDBMS engine itself is 20 years stale.
The only difficult part in arguing this is that RDBMS != SQL != RelationalAlgebra, and it’s very often forgotten
If a manufacturer is unwilling to guarantee/monitor the lack of sesame in their food, and you having a presumably severe sesame allergy… isn’t it correct not to be eating that food?
Like previously you trusted their lack of sesame based on vibes, which you probably shouldn’t have been doing, and now they’re explicitly telling you not to trust them on this; this seems to me strictly better. You’ve lost a choice that never really existed in the first place
An actually unintended consequence would be if they introduced sesame because they were going to have to put the label on it anyways
The truly correct answer is give the player a mild damage aura/aoe and let the mobs die at your feet on their own. Running away breaks an annoying amount of mechanics, like ingredient farming.
The power fantasy just needs them to die trivially. So just do that.
If you’re a shareholder in 5 companies, each owning 2 parcels of land, each with their own PoA, and you yourself hold land — then you have “influence” into 6 votes, though only direct ownership of 1 vote
Not liking it and having the conceit to replace it (and more importantly, shove your replacement into prod) are entirely different actions. The first is always legal. The second is more often questionable than not
Given that they already made the billion dollar mistake, I find their handling for nulls the best possible thing they could do at this point. I’d hardly call it crazy — rather, it’s exceedingly pragmatic.
I mean, they have to explicitly unpack the error and then choose to do nothing with it. It requires roughly the same amount of code to do the same with discarding an exception.
Except with a Result type the fact that an exception can occur and should be handled in the first place is explicit.
The problem if anything is that you MUST say something about the error case, despite the common scenario being “pass it forward” — the same reason exception do this by default. Which is also why rust for example special cases Result with the ? operator to do exactly that
I don’t understand how splitting a query up would have any relationship to index utilization; the planner should trivially pick up on it?
Also are you sure you’re not solving a different problem[0]? Doing joins manually being faster doesn’t smell right, except in the case of data duplication increasing total resultset size substantially
Like the cost of increased network load from not filtering through the join should outweigh anything else in the equation
https://learn.microsoft.com/en-us/ef/core/querying/single-sp...
reply