ants_a

That's not the motherboards fault, the PCIe controller is on the CPU and needs to have corresponding I/O pinout on the socket. And even from the CPU manufacturer side, it's not artificial market segmentation. The I/O die alone on an EPYC/ThreadRipper Pro is more than double the die area of the CPU, GPU and I/O chips in a Ryzen 7 7800, and it's on a single chip which makes yields way worse. The socket and package need 1700 connections in one case and 6000 on the other. The high I/O CPU is way more expensive to manufacture, and on the lower end the prices start at ~1k for 512 GB/s of full duplex PCIe bandwidth and 12 memory channels.

For well scaling workloads optimizing for efficiency is optimizing for performance. For serial workloads even one P-core is enough. There aren't too many workloads in the middle that scale but only to a few cores.

Networking doesn't have to have high latency. You can buy network hardware that is able to provide sub-microsecond latency. Physical distance still matters, but 10% of typical NVMe latency gets you through a kilometer of fiber.

Nice, I hacked together something similar many moons ago, it looks like some fine folks have kept on maintaining and improving it: https://github.com/fschulze/sqlalchemy_schemadisplay

Useful to have in a CICD pipeline so you always have an up-to-date schema diagram available.

Is there a reason why this is implemented in Rust instead of plpgsql? At first glance I didn't see it using any features that would need a loadable extension. Plain SQL based solution would make using it on managed database services much easier.

The unexpected part for me was not the lack of temporal locality, but which cache it thrashed. The whole dataset fits into buffer cache so one might think that the lack of locality is not that important...

B-trees index random UUIDs perfectly fine, it's just that range scans over the resulting indexes cause random access patterns that interact really poorly with caches when data size exceeds cache size. The blog was about an interesting case when dataset fits into buffer cache, but the random access pattern still hurts because of other caches.

I agree, though it's not the uniqueness, but not null constraint that matters here. PostgreSQL could, but doesn't right now, use the not null constraint to optimize the former to the latter.

The actual case came to my attention because an ORM insisted on generating the count(uuid) variant and I thought it peculiar that the performance difference was so large. But silly ORMs aside, the same problem will happen on any index only range scan over an index that has uuid in it. For a more realistic case, a `count(*) where somecol = 'value'` with a `(somecol, uuid)` index will hit the same problem. I thought the rather hidden single entry visibility map buffer reference cache was an interesting example where random ordering can cause performance problems.

Those global variables would be converted to thread locals and most of the code would be oblivious of the change. This is not the hard part of the change.

As a counterpoint: https://brandur.org/text

Why is revoking permissions to run deletes/updates not an option?

There is the pg_hint_plan extension that gives most of what you would want in a hinting system.

I think a better fix lies in the direction of making queries more of a first class object with options to nail down plans, add custom logic to pick plans dependent on parameter values, etc.

All of the cheap tabletop cooktop I have seen have terrible cycling at lower powers, there seems to be two power levels and when you need something below the lower one, it cycles power at ~10s frequency. In contrast a Bosch integrated cooktop from a couple of years ago also does cycling, but seems to have more power levels available and the cycling is faster, around 1Hz or so. At least for me that is good enough.

My issues with it are more about inaccurate placement causing hot and cold spots and if you move a pot it can triggers cookware detection, which then clicks different coils on and off for 5-10s before it is satisfied with the new configuration. Both of those issues are probably exacerbated by the "FlexInduction" system that promises one large automatic cook area.

I'm hoping that power electronics development for electric cars creates some innovation in this area, but it's really hard to tell because there are no useful review sites and there aren't any places that let you take a cooktop for a testdrive.

With most cookware it's pretty obvious where the coils are when trying to simmer. With thinner stuff like carbon steel the hot spots can be pretty nasty: https://www.youtube.com/watch?v=pifD__DIxGU

Setup credentials for an S3-compatible bucket and you will have backups + point-in-time-recovery capability. For restores there are a few different options. If you just flat out delete the persistent volumes you will get an automatic restore to latest state in the archive (RPO of ~16MB of transaction log in case of unclean shutdown). Or if you just need to recover some data from a previous state, you can clone a new cluster from backups specifying a timestamp to recover to. Or in case you strictly need to get the same cluster up to a previous state, you can manually exec into the container stick it into maintenance mode and replace the contents with a backup.

Simpler fix is to upgrade to fixed version and reindex concurrently any indexes that could have been affected.

That's the availability part. If a system is unable to make progress it is not available.

My experience is that the problem with producing business software is not the lack of programming knowledge. Rather it's a lack of people who understand the business and are capable of abstract thought and formalizing processes. I don't see AI helping with that any time soon.

A normal vacuum will also defragment page contents, see PageRepairFragmentation()[1], which is called during normal vacuum from lazy_vacuum_page().

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f...

In PostgreSQL you would group by date_trunc('month', transaction_date)

Or alternatively, toss in a network interface and have drives PXE boot an application specific firmware and spin up a ceph-osd or similar server.

EU is already trading CO2 at 60€/t.

They were behind for a few years in the beginning of 2000's in the P3 - Core 2 era.

Something does not compute. $1000 should be getting them ballpark 10'000 kWh of power. That is 14 kW of constant power use. Typical largest residential GSHP over here is 15-18 kW of heating at 4 kW compressor power. (usually COP in range 4-5 is specified at 0C input, 35C output) So unless the GSHP is woefully undersized, the house is terribly insulated and the resistive booster heater is running at full tilt, something is wrong with those numbers.

For saving money on heating the first step should be to waste less heat rather than making the wasted heat cheaper.

The optimization engine is of course great (despite occasionally missing hard), but I am not referring to it. I am referring to the way that PostgreSQL executes query plans, the way rows are pulled up the execution tree, is very similar to first iterations JavaScript engines - a tree based interpreter. Picking out columns from rows and evaluating expressions used to work the same until PG11, where we got a bytecode based interpreter and a JIT for those. But so far rows are still working the same way, and it hurts pretty bad when row lookup is cheap and the rows end up either thrown away or aggregated together with basic math.

From my experience of benchmarking these databases on scientific data (highly regular timeseries) and looking at the internals of both, these kinds types of number happen when answering the query needs crunching through many rows, but the output has few. i.e. the queries are filtering and/or aggregating a ton of input rows, that can't be excluded by indexes or queried from preaggregations.

From what I can tell it comes down to execution engine differences. TimeScale, even with compressed tables, uses a row by row execution engine architecturally resembling IE6 era JS engines. ClickHouse uses a batched and vectorized execution engine utilizing SIMD. Difference is one to two orders of magnitude of throughput in terms raw number of rows per core pushed through the execution engine.

Postgres/TimeScale could certainly also implement a similar model of execution, but to call it an undertaking would be an understatement considering the breadth and extensibility of features that the execution engine would need to support. To my knowledge no one is seriously working on this outside of limited capability hacks like vops or PG-Strom extensions.

There is a specification for updating charging cable firmware.

There are plenty of thin laptops with USB-A ports. Thinkpad X1 is both thinner than a macbook and has two USB-A ports. And there are laptops just 2mm thicker than a Macbook Air that have ethernet via some clever mechanical engineering.

Postgres has much more featureful query language, and at tens of thousands of rows the performance difference is irrelevant. The story becomes different when answering a query has to touch millions of records and the answer is needed in milliseconds.

The comparison to a turbo got me thinking if some of the compression energy could be recovered in the expansion stage. Turns out the answer is yes, but the energy recovery is limited to 7% at best: https://www.sciencedirect.com/science/article/pii/S187661021...