Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
Sesse__
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
271.
▲
by
Sesse__
1y ago
Some are bit-by-bit (e.g. the PPM family of compressors[1]), but the normal input granularity for most compressors is a byte. (There are even specialized ones that work on e.g. 32 bits at a time.) [1] Many of the context models in a typical
272.
▲
by
Sesse__
1y ago
“Memory movement”? None of the instructions you list involve memory. I find the perfect hash implementation a bit weird; it seems to obfuscate that you simply look at the lowest two bits (since they differ between the four values). You can
273.
▲
by
Sesse__
1y ago
> Of course when the interviewer asks me to use "any language", I'll assume they want Python or Java or C++ or Rust, not Bash or ALGOL 68. When I did interviews, I used to ask for “any imperative language”. Most people cho
274.
▲
by
Sesse__
1y ago
It's confusing nomenclature, but Postgres' “heap” is not a heap (B-tree) data structure. It is just a bunch of blocks all on the same level, similar to how the “heap” in an operating system (as opposed to the stack) is. Notably, y
275.
▲
by
Sesse__
1y ago
That link directly contradicts what you are saying. > This means that in an ordinary index scan, each row retrieval requires fetching data from both the index and the heap. Note that it says _index and the heap_. Not _index and the prima
276.
▲
by
Sesse__
1y ago
If you're interested in safeguarding data for the future, then I don't think the model of “my backup immediately disappears once the account runs out of money” gives me anything resembling a cozy feeling at all.
277.
▲
by
Sesse__
1y ago
I'll take a [citation needed] on that one.
278.
▲
by
Sesse__
1y ago
It would be interesting to see how OrioleDB does with more OLAP-like loads. From when I spent a lot of time benchmarking this, the indirect index design was _the_ main reason why MySQL+InnoDB was losing significantly to Postgres on TPC-H (w
279.
▲
by
Sesse__
1y ago
OK, so basically no big change with PG 18, and for the time being, one needs to basically your own Postgres? Would be really nice with a pgdg package, as this is definitely the kind of thing I would want to test in a separate cluster :-)
280.
▲
by
Sesse__
1y ago
I assume you get this a lot, but how much patching is left in PG 18?
281.
▲
by
Sesse__
1y ago
You get basically most of the advantages of a B-tree-oriented table, but also most of the disadvantages AFAIK. In particular, any index lookup/scan is going to take twice as long (index blocks don't point to the place on disk, the
282.
▲
by
Sesse__
1y ago
tar --listed-incremental=foo.snar -cf - . | gpg --encrypt -r <key> > nightly.gpg You're welcome.
283.
▲
by
Sesse__
1y ago
What? My phone has a perfectly working 802.11 chipset, which is able to talk to my very own machines that are not in a cloud, no manual connection needed. This is purely a software/ecosystem issue.
284.
▲
by
Sesse__
1y ago
Any backup that needs manual intervention is no backup.
285.
▲
by
Sesse__
1y ago
There are a couple of problems with the existing backup: 1. It is non-incremental. This means you'll need about as much free space on your phone as your Signal database takes, and it may take many hours to make if your database is larg
286.
▲
by
Sesse__
1y ago
> I mean, sure. So what does the solution look like? Obviously taking on fewer such liabilities?
287.
▲
by
Sesse__
1y ago
> Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful. You don't think making adding dependencies incredibly slow and painful would make peop
288.
▲
by
Sesse__
1y ago
Huh, interesting, I didn't know this was a thing at all. But you still need to make sure you don't have a stupid customer sending 1000baseLX with direct detection in the other side for this to work. :-)
289.
▲
by
Sesse__
1y ago
Thus going away (see my other comment in the same subthread).
290.
▲
by
Sesse__
1y ago
I don't know exactly how long gives you too much dispersion (obviously depends on the fiber), but if it's short enough you just don't need to care, indeed. I don't work with this myself, but my understanding is that you
291.
▲
by
Sesse__
1y ago
The two-sided Laplace transform would probably have made his head explode.
292.
▲
by
Sesse__
1y ago
You know that if you have the Laplace transform, you can just insert s = iω and then you have the Fourier transform, right? :-P (Or jω, if you prefer that notation)
293.
▲
by
Sesse__
1y ago
AFAIK yes, but if that's your goal, a far easier solution is to just use transmission standards that don't care about dispersion (coherent detection). E.g., all 100gig transmission already does not care about it.
294.
▲
by
Sesse__
1y ago
> "The new design maintains low losses of around 0.2 dB/km over a 66 THz bandwidth and boasts 45% faster transmission speeds... 0.2 dB/km is already a pretty common loss ratio, though. It's true that you won't ge
295.
▲
by
Sesse__
1y ago
It's true, but for most cases, the volume of a fiber is not the problem anyway. Latency is a problem most of us somehow bump into every day, while most fibers in the ground are nowhere near what you can push out of DWDM (e.g., off-the-
296.
▲
by
Sesse__
1y ago
And on the next one, a SIMD-heavy searcher thingie (where it found a real bug, though thankfully “only” reading junk data that would be immediately discarded!), it went from 7.723 to 379.56 seconds, a whopping 49x slowdown.
297.
▲
by
Sesse__
1y ago
FWIW, I just tested it on a random program I wrote recently, and it went from 2.085 seconds with Clang+jemalloc to 18.465 seconds with Fil-C. (No errors were reported, thank goodness!) So that's a 9x new worst case for you :-) It'
298.
▲
by
Sesse__
1y ago
> Great examples are things like shells and text editors I regularly get annoyed that my shell and text editor is slow :-) I do agree on principle, though.
299.
▲
by
Sesse__
1y ago
It's filesystem-dependent. In particular, tmpfs will work. To the best of my knowledge, no “normal” filesystems (e.g., ext4, xfs) will.
300.
▲
by
Sesse__
1y ago
I've tried to use Z3 to find hash collisions in a simple hash, and it was amazingly bad at it. It took forever, whereas just trying random values until some were (multi)colliding was sub-second :-)
More ›