oatsandsugar

This is surprisingly beautiful:

> The word foil comes from the old practice of backing gems with foil to make them shine more brightly.

How does this law allow for non-democracies?

Some favorites:

* https://en.wikipedia.org/wiki/User:Junnn11

* https://en.wikipedia.org/wiki/Timeline_of_the_far_future

* https://en.wikipedia.org/wiki/Ha-ha

Oh I've been loving this series: its like clickspring for automata.

The magnetic hands were such a cool idea, and the way he builds the springs for the bowden cables in ep 2, gorgeous!

Thesis is "crypto millionaires squeeze out other consumers from high demand goods, loss of crypto value reduces demand for those and thus benefits other consumers"

The "choose your date by selecting a substring of pi" is absolutely incredible.

[This paper] show[s] that forecasters, on average, over-estimate treatment effects; however, the average forecast is quite predictive of the actual treatment effect.

When I was in Venture, I did a tonne of research into the Nix ecosystem.

Fast forward to now, a new hire at the startup I work at, on his own volition, implemented a Nix flake day one at the company. Within the week, a bunch of our engineers were using it.

Super cool to see, mainly because of the decreased frustration in setting up our dev environments.

Thank you mate! fixing

Author here: commented here about how you can use async inserts if that's your preferred ingest method (we recommend that for batch).

https://news.ycombinator.com/item?id=45651098

One of the reasons we streaming ingests is because we often modify the schema of the data in stream. Usually to conform w ClickHouse best practices that aren't adhered to in the source data (restrictive types, denormalization, default not nullable, etc).

Author here—this article was meant to highlight how you can optimize writes to CH with streams.

If you want to directly insert data into ClickHouse with MooseStack, we have a direct insert method that allows you to use ClickHouse's bulkload methods.

Here's the implementation: https://github.com/514-labs/moosestack/blob/43a2576de2e22743...

Documentation is here: https://docs.fiveonefour.com/moose/olap/insert-data#performa...

Would love to hear your thoughts on our direct insert implementation!

Timely! We're redesigning our blog, will keep you posted

Co-author here, we used Debezium here because it supports many different databases. Unfortunately, no sqlite support—my understanding is as an embedded db it lacks some of the prerequisites that Debezium relies on.

Have you run CDC from sqlite? would love to hear how you did it and to try build a demo with MooseStack

I think my favorite part was the ability to use the same Drizzle TS data models created for Postgres for creating tables in ClickHouse

I mean the Azerbaijan one goes so hard:

https://spaceexplorationlogoarchive.webflow.io/loghi/azerbai...

Author here: I wrote out some worked examples about how ClickHouse's table engines affect how CDC updates and deletes are treated (on initial write, and on merge), coming to the conclusion that the ReplacingMergeTree is the goldilocks table engine for most CDC use-cases.

One of the works:

> In early work, El-Badry developed a method for identifying binary stars in spectrographic datasets. More than half of stars exist in binary systems, but they are often too close together to be differentiated with available technology. El-Badry overcame this challenge through targeted statistical analysis of existing spectral data.

Another

> Porras-Kim selected fragmented objects of unknown origins from the storage shelves of the Fowler Museum at UCLA, whose collections span the arts and cultures of Africa, Asia, the Pacific, and the Indigenous Americas. Her resulting installation, entitled Reconstructions, brought together the artifacts with drawings and sculptures that prompted viewers to consider how the textile fragments, pottery shards, and other orphaned objects functioned and came to be acquired by the museum.

I love that these grants go to such an incredible variety of impressive folk—from music to astrophysics.

That's really intuitive, especially your description of column notation. Excited to read your other guides!

Also, HT to your user name! Egon Schiele is one of my favorite artists! Loved seeing his works at the Neue in NYC.

Apple coding interview?

if you don't tariff imports lol

It is so beautiful, but it is definitely on the list of "touristy stuff" in Barcelona.

Dig up

You have a more generous sarcasmometer then me :)

> perhaps rightly so?

citation? You don't even say why he has a concern, so how can you say they are correct?

But coal is super subsidized? the price of new solar is cheaper than the price of new coal

Yeah, this is mainly aimed at applications that need an OLAP backend (think user facing analytics, or a database that backs chat applications)

> The sane middle ground is libraries that give you nicer ergonomics around SQL without hiding it (like Golangs sqlx https://github.com/jmoiron/sqlx). Engineers should be writing SQL, period.

The blog suggests that an ORM for OLAP would do exactly that

Also for metadata queries, OLTP was faster. But these were the difference between the blink of an eye and two blinks of an eye.

I’ve seen many benchmarks on OLAP performance, but I wanted to better understand the practical impact for myself, especially for LLM applications. This is my first attempt at building a benchmarking tool to explore that.

It runs some simple analytical queries against ClickHouse, Postgres, and Postgres with indexes. To make the results more tangible than just a chart of timings, I added a "latency simulator" that visualizes how the query delay would actually feel in a chat UI.

With a 10M row dataset: ClickHouse queries are sub-second, while Postgres takes multiple seconds.

This is definitely a learning project for me, not a comprehensive benchmark. The data is synthetic and the setup is simple. The main goal was to create a visual demonstration of how backend latency translates to user-perceived latency. Feedback and suggestions are very welcome.