Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
andersmurphy
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
61.
▲
by
andersmurphy
4mo ago
This a thousand times. The bigger models also have a habit of overcomplicating things.
62.
▲
by
andersmurphy
4mo ago
I believe the point they were making is you can have millions of virtual threads on the JVM no problem. Your information on the JVM is outdated.
63.
▲
by
andersmurphy
4mo ago
Really clever!
64.
▲
by
andersmurphy
4mo ago
Seems like a pretty close copy of Carson's (of HTMX fame) agent.md from 5 months ago https://gist.github.com/1cg/a6c6f2276a1fe5ee172282580a44a7ac
65.
▲
by
andersmurphy
4mo ago
:cache_size 1562 :page_size 4096 :journal_mode "WAL" :synchronous "NORMAL" :temp_store "MEMORY" :busy_timeout 5000 (Synchronous FULL in context where it matters) But, it depends on the shape of your dat
66.
▲
by
andersmurphy
4mo ago
You mean 100k+ right?
67.
▲
by
andersmurphy
4mo ago
Seems fine at billions of rows in my experience.
68.
▲
by
andersmurphy
4mo ago
It doesn't block reads. Single writer systems are often faster than concurrent writers no coordination overhead and you can batch.
69.
▲
by
andersmurphy
4mo ago
Hundreds of thousands*
70.
▲
by
andersmurphy
4mo ago
Yeah sqlite on anything but a directly attached nvme is a bad time if you're using it for a web server.
71.
▲
by
andersmurphy
4mo ago
I think a lot businesses build large distributed systems prematurely. They don't know what they don't know.
72.
▲
by
andersmurphy
4mo ago
What on earth needs thousands of instances? Are you building a CDN? Most apps can be a single server or sharded by business/region. Honestly, this whole leys run loads of nodes seems to have sprung up from languages that are slow oe do
73.
▲
by
andersmurphy
4mo ago
Why do you need libsql? Single writer tends to scale better than concurent writes.
74.
▲
by
andersmurphy
4mo ago
What's massive amount concurrent writes? What's big data?
75.
▲
by
andersmurphy
4mo ago
In this demo each T in TPS is two updates over a billion rows and most importantly skewing high on row lock contention. On a 5 year old macbook, using a dynamic language. Isolation level serializable and synchronous full (so max durability)
76.
▲
by
andersmurphy
4mo ago
Yes, it's still slower on the same machine, even with unix domain sockets. It doesn't play nice with other things running with it in practice. JVM and postgres on the same box is a textbook bad time.
77.
▲
by
andersmurphy
4mo ago
Because local postgres is a bad time unlesss it's the only thing running on the server. Even then sqlite will smoke postgres (even with unix sockets). The point is to survive the Pareto row locking problem you need to move away from a
78.
▲
by
andersmurphy
4mo ago
Thing is SQLite scales better than both those network databases [1] if you're prepared to stick with one big machine (+ a standby). This is even more obvious when you start doing transactions processing an row locks across the network
79.
▲
by
andersmurphy
4mo ago
Wonder if that's to do with dark mode or something? I had the same issue in dark mode on mobile on duckduckgo.
80.
▲
by
andersmurphy
4mo ago
Oh LZ4 nice! Also the fact that this is in python makes this even more impressive.
81.
▲
by
andersmurphy
4mo ago
Can Claude use it?
82.
▲
by
andersmurphy
4mo ago
Nice. The build your ritual is quite a cute feature.
83.
▲
A Trillion Characters
(characters.fastserial.com)
36 points
by
andersmurphy
4mo ago
|
16 comments
84.
▲
by
andersmurphy
4mo ago
I wonder if it's being done to improve revenue nunbers without changing an enterprise contract? Oh what's that your token usage went up because some of your developers switched to a new model? That sounds like a you problem. I thi
85.
▲
by
andersmurphy
4mo ago
Didge isn't that loud unless you're really going for it. Nothing compared to bagpipes.
86.
▲
by
andersmurphy
4mo ago
Yeah that should be 2.8-3.3cm for sure.
87.
▲
by
andersmurphy
5mo ago
> First, I made this decision and I own it... Always reminds me of: > Failure is growth. Failure is learning. But sometimes failure is just failure. I think... I'm sorry. I didn't think it would be this hard. But goodbyes ar
88.
▲
by
andersmurphy
5mo ago
The low powered MCU (Raspberry Pi RP2350B) has RISC-V: Dual ARM Cortex-M33 @ 150 MHz + Dual RISC-V Hazard3 @ 150 MHz
89.
▲
by
andersmurphy
5mo ago
Yup do what works best for you. I do the opposite I don't support path params. Means your router can just be a simple map/dict. Query strings avoid all the hierarchy/taxonomy problems you run into with path params.
90.
▲
by
andersmurphy
5mo ago
The problem is row locks when using interactive transactions over the network and contention. That can absolutely kill your performance with postgres, there's not really anything you can do to get around it (other than avoid interactiv
More ›