MSSQL can handle 32k open connections no need to run a pooler in front of it, can PG do 32k connections and a process for each?
MSSQL shares cached query plans between connections including jitted code, PG cannot do that and the changes needed to make the plans cross process portable would be extensive while sharing between threads is just normal code sharing between threads.
>Unsafe extensions can take down the whole instance in the threaded model, processes contain the blast radius to that connection.
MSSQL has its own task scheduler with the ability to kill etc, its like its own OS internally in that respect but yes there is no memory protection there for unmanaged code.
It doesn't really have unsafe extensions other than it is possible to create extended stored procedures which could do bad things, very frowned upon. If you were concerned about that you would run that database in its own instance (process).
>I'm thinking the buffer cache and locks and WAL coordination are just as fast - it's just mmap'd SHM into each process.
Plan caches contain pointers to executable code and sometimes jitted code, this cannot be just shared to another process with a different address space and work, this is code not data, to transport between processes it needs to be serialized in a way that is not tied to process memory including things like ASR, certainly doable but since it wasn't designed that way much needs to be changed vs just sharing between threads.
Interesting I have definitely used the distinction between null and empty string quite a bit in MSSQL and matches most programming languages.
Another issue that used to exist was Oracle table name were limited to like 12 characters or something so I have seen horrible abbreviated table names to fit in the Oracle limitation even in other DB's due to some systems being able to run on both MSSQL and Oracle even though SQL Server has a 255 char limit for table names.
Each PG connection being a whole process does not scale like MSSQL that uses a thread per connection which has a max of 32k per instance.
There are no need for connection poolers in front of MSSQL although it is normal to pool connections in the client application which may hold hundreds open typically in a web server.
This also allows MSSQL to more easily share cached query plans between connections since its just sharing executable code between threads.
For PG to do plan caching it would need to serialize the plan between processes and that would require some significant work since it was never designed that way.
PG has it obvious unix roots using processes instead of threads, MSSQL coming from Windows where new process are expensive and there was no real fork, but threads are cheap uses that approach instead.
I don't agree, a relational database is not required to have a particular storage engine or format, that is an implementation detail.
There are other relational databases that have both kinds of storage engines and some use both on the same table (row based insert with column based migration and secondary column store indexes: https://learn.microsoft.com/en-us/sql/relational-databases/i...
Just like you can have b-tree based table storage vs heap in the case of index organized tables / clustered indexes (which pg doesn't have) you can choose column based instead the logical data model is still the same relational model.
FSD is obviously very different than normal cruise control and I cannot see an argument why a system that knows its heading down a dead end street at more than double the posted speed limit would allow such and accelerator override and not apply automatic emergency braking, it makes no sense, that serves no purpose while leading to a tragic outcome.
Moving off a railroad track at what maybe 15mph max is very different than doing 70mph down a cut de sac double the posted speed limit. I am not saying FSD should prevent any forward movement, how fast can it go in reverse? Probably something like that.
I guess that seems ridiculous to me. I could understand if its some sort of government regulation, but if you want to ram a house or anything else or go double the posted speed limit then you should be required to disengaged FSD and go manual, obviously.
There are plenty of videos of stuck vehicles that have a hard time due to traction control disallowing power even with full accelerator pedal, this is not a foreign concept in a modern vehicle. Here is one example, they refer to traction control as the soup nazi, no power for you! : https://www.youtube.com/watch?v=WLVae7-N_Vs
It's a feature to look for in a off road vehicle if it has a traction control disable and even ABS disable on motorcycles, this is an explicit command to disable a safety feature that typically resets when power cycled. Not sure why FSD would allow overriding an obviously unsafe situation, the operator can disable the whole thing at any time if they wish to do so and go manual with a specific on screen command rather than hitting a pedal right next to the other stop pedal with your foot resting between them otherwise.
That is the current public information if it is true is only the driver at fault?
What are the alternatives? FSD on and no driver input? FSD off and driver rammed house without assistance?
This is mostly a thought experiment for me provoked by the incident after being impressed to buy one.
Tesla obviously wants to blame driver to absolve themselves while it’s obvious to me driving with FSD is not the same as driving normally when it comes to reacting to unusual circumstances and a certain amount of responsibility is given to the FSD.
Based discussion with the younger owners of FSD it’s obvious driving around manually will be like driving stick shift soon or writing in cursive, an atrophied skill that the younger generation will have no use for.
Why does the FSD blindly accept accelerator input in the face of a dead end cul de sac with much lower speed limit? Is this some sort of regulation?
I have driven normal cars that cut power and brake if they detect a perceived dangerous situation usually annoyingly and in error. Traction control will also cut power to prevent wheel slip regardless of pedal position.
So my understanding is the telemetry shows the FSD was on and driver held the accelerator down the whole time and the car did 70+ mph into the home.
Tesla proponents say it’s the drivers fault since the accelerator was held while dissenters say why didn’t the FSD step in.
I happened to just test drive a new model Y having never done so before and not being very interested for various reasons. I may be getting the new L version when released soon in the US it was very impressive especially for the current price compared to the competition and how impressive FSD was is part of my change of heart.
You can hold the accelerator while FSD is engaged to tell it to go faster, this made sense but I assumed it was a suggestion not a go down with the ship command.
So the question is should FSD prevent unsafe speed and ramming objects when engaged even if operator holds accelerator. Based on what I saw with FSD it should know the speed limit and that it was heading to a dead end cul de sac ahead of time and the cameras should see the house near the end perhaps too late to stop but at least slow down.
The argument is I have heard there are actually regulations requiring it to accept accelerator input regardless but I have used other vehicles that emergency brake based on sensor input while manually driving even somewhat annoyingly when no actual obstruction exists (phantom braking).
My thoughts are FSD was on so the accelerator is a suggestion not a to the death command and it should have not allowed the vehicle to enter the house at 70 mph. So while the driver is at fault so is FSD and the complacency it presents contributes to driver error.
Most likely explanation is the driver panic hit the accelerator instead of brake. From driving with FSD it seem easy to get complacent and then do something like that when needing to take over vs normal driving where you are already engaged with braking and accelerating manually.
Why EAC3 compressed audio instead of uncompressed PCM in Dolby MAT like an Apple TV?
E-ARC has the bandwidth for 32 channel/object uncompressed Atmos no need to do EAC3 compression. This is why Apple TV and Windows use Dolby MAT uncompressed, not lossy and more direct.
You can decode TrueHD to PCM + metadata then just send out in Dolby MAT although would be limited to 44/16bit but then so is EAC3 I believe. True HD can go higher sampling and bit rates over E-ARC since it's compressed and why it's used.
Only reason to use EAC3 is to fit over lower bandwidth ARC instead of EARC, my LG tv will convert/compress Dolby MAT uncompressed from Apple TV to EAC3 DD+ if EARC is disabled and it falls back to ARC due to bandwidth constraints.
These are typically LFP batteries that already have significantly longer cycle life and are a much more stable chemistry than the NCA / NCM cells in normally found in western cars.
The cells are also designed toward charge speed vs capacity (more copper less lithium) and cooling systems capable of keeping batteries at good temps even with 10C charging, so overall they are shooting for million mile batteries, I don't think people realize how robust LFP's are and that China is all in on that chemistry and the progress being made there.
Yes charging at home is great until you need to go on a long road trip or you live somewhere without the ability to charge overnight.
I can charge overnight but I am not going to give up a gas car until the fast charging situation is better. I do have an EV around town and its great, but the road tripper is gas, looking at PHEV as a middle ground for next car.
I can fill my gas car in 5 minutes, this makes an EV essentially no different. I don't want to sit around 15 minutes to fill up my car on a road trip that also increases stall throughput 3X.
I think Chinese are taking the correct approach focusing on charge speed rather than range, although their range is going up too using LFP batteries that are very safe and have long cycle life.
I remember the original Scorched Earth being one of the few games that could actually do SVGA graphics at the time.
Most games of the era where 320x240 8 bit 256 colors, I had a 286 with 800x600 SVGA monitor and that game could actually use it although it was only 4 bit 16 color, don't think I ever played the 256 color in the last version.
MSSQL shares cached query plans between connections including jitted code, PG cannot do that and the changes needed to make the plans cross process portable would be extensive while sharing between threads is just normal code sharing between threads.