I don't think it's that different from pointing out that registering and/or operating a company in e.g. Delaware or Texas is a very different experience from doing so in New York.
If the status column changes, and an index depends on the contents of that status column (be it by referencing it in its columns, or in the index's WHERE filter) then an update of the status column will prevent the HOT optimization from being applied.
The national elections in NLD have a single ballot in the whole country, with 10+ parties who each get a column of their candidates on the ballot, and with one box for each of the candidates. In these elections for the 150 seats of parliament, often there are 200+ candidates listed total. As a result, the ballot sheets need to be quite large and so are quite far into the 'unwieldy' part of the handling spectrum.
This size issue also complicates verification and counting, because you have to verify that of all checkboxes, exactly one is filled in, and sorting/counting needs to do this for practically every ballot.
There has been some experimenting with changing the ballot to a 'party' and 'list number' ballot, where you fill in the party of your chosen candidate together with their number on the party list, but AFAIK that has not (yet?) been approved for wider use.
The order returned from the Index Scan is not the ordering requested by the user, so there would still have to be a full (or topk) Sort over the dataset returned from the index scan, which could negate the gains you get from using an Index Scan; PostgreSQL itself does not produce merge join plans that merge a spread of index scans to get suffix-ordered data out of an index.
Epic wasn't fined for putting things on sale. Instead, it was fined for putting pressure on children to buy things that were put on sale; e.g. through wording like "Get it now" and "Grab it", and through design.
There is also a lot of money, there is also good management, and there are also lots of incentives.
But management depends on your manager; at scale it becomes likely there are bad apples in every management tree. Incentives may not align with what you want or need, with work From Home policies getting shrunk. Even money sometimes is a point of contention.
That's why they're called generic parameters, not template parameters; the code is generic over all possible parameters, not templated for every possible parameter.
It's true that the transistors are on the order of 50nm, but the conduits for getting the electrons to those transistors are presumably a bit smaller than that.
Probably not 7nm small, but not the full 50 nm either.
Facebook Nederland B.V. is just one of the defendants; the other defendants are Meta Platforms Ireland (based in Ireland), and Meta Platforms Inc. (the main company, based in the USA)
The Dutch subsidiary has been acquitted, as it only managed advertisement income, not the app design.
Meta Platforms Inc. has been acquitted, as it itself doesn't directly provide apps or services in Europe (nor the Netherlands) - legally that's managed by Meta Platforms Ireland and so not Inc.'s responsibility.
Meta Platforms Ireland has been ordered to implement these changes, enforced by the up to 5 million euro fine (see pages 20 and 21 in the verdict)
The judgement requires Meta to change their platforms within 2 weeks so that the user's choice is persistent. If not implemented in 2 weeks, there is a daily penalty of €100'000, up to a maximum of €5 million.
> They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade
Minor versions of PostgreSQL have constraints that major versions don't have; in that minor versions in principle don't see new features added. This allows minor versions of the same major release to run against the same data directory without modifications.
However.
Major versions add those new features, at the cost of changes to internals that show up in things like catalog layout. This causes changes in how on-disk data is interpreted, and thus this is incompatible, and unlike minor releases this requires specialized upgrade handling.
Those are some great features. More than I remembered, and it's only been a year.
Personally, I'm very happy to see parallel builds for GIN indexes get released - (re)index time for those indexes is always a pain. I'm looking forward to further improvements on that front, as there are still some relatively low-hanging fruits that could improve build times even more.
I think that "under review" claim is doing some very heavy lifting, especially when it relates to their changes to index tuple lifecycle management. The patches that have been submitted are unlikely to get committed in full anytime soon, even after substantial changes to the patches' designs.
PostgreSQL just has not been designed for what OrioleDB is doing, and forcing OrioleDB's designs into PostgreSQL upstream would a lot of (very) sharp edges that the community can't properly test without at least a baseline implementation - which critically hasn't been submitted to upstream. Examples of these sharp edges are varsized TIDs, MVCC-owning indexes, and table AM signalled index inserts.
There are certainly ideas in OrioleDB's designs that PostgreSQL can benefit from (retail index tuple deletion! self-clustering tables!), but these will need careful consideration in how this can be brought into the project without duplicating implementations at nearly every level. A wholesale graft of a downstream fork and then hoping it'll work out well enough is just not how the PostgreSQL project works.
The existence of a sidewalk implies the existance of a road that is used for all traffic except foot traffic, such as bikes. Why are you forcing the situation onto the sidewalk?
I was talking about a pedestrian road, considering the 'historical' setting of the GP post.
> Do you really need it explained to you how a bike is more dangerous to pedestrians than a runner?
No, I do understand that there is (some) more danger to a bike. But a bike also provides an elevated viewpoint to the cyclist, allowing for a better overview of the traffic situation, allowing the cyclist to better participate in traffic.
> more difficult to safely maneuver around short of standing the side and stopping to let them pass.
Most of the time roads are wider than the turning radius of a bike, especially at low speeds (approx 1.5m). Why would you need to stand aside to let someone pass if you have such wide roads?
I see your point, but Amsterdam generally has separate lanes for cars, bikes and foot traffic.
The point I was making is that it is safe to use a bike in foot traffic areas if you slow down to match the expected speeds of your surrounding traffic; such as using a bike in the historical city center of e.g. Amersfoort or Utrecht, where there is usually a lot of foot traffic and little car traffic, and no separate bike lanes.
Uh, what? Reaching 15km/h is not unheard of for running either, so why would that be waaaaay too fast on a bike in mainly pedestrian areas? Sure, the bike should slow down to lower speeds than their norm to ensure safety for all people involved in traffic, but isn't that no different from how cars shouldn't go 100km/h+ in city centers?