anarazel

43 ms·

331.
by anarazel 5y ago
The last time I checked - maybe 3-4 months ago - the ktls implementation in openssl still seemed, um, somewhat fragile. Undocumented behaviour changes, missing error handling, ...
332.
by anarazel 5y ago
Unless the app servers are particularly large, or the app-side ORM connection pool doesn't work well (e.g. because the number of concurrent requests changes sufficiently over time that thread/process count constantly changes), I&#
333.
by anarazel 5y ago
> it doesn't really make much sense to prioritize this inside the database server itself. I wouldn't go that far. There's a lot of things that are hard to do within an external pooler, unless the pooler uses a 1:1 connecti
334.
by anarazel 5y ago
There has been some work towards that - things did get cheaper in 14. Note that you very well might still want a separately run pooler for some workloads - having local poolers on application servers can be good for latency.
335.
by anarazel 5y ago
Which pre-existing libraries have been integrated that way into the kernel? There's a few tiny pieces, but largely you can't just use pre-existing libs inside the kernel.
336.
by anarazel 5y ago
I just wish they had a decent way to execute programs with arguments that might include spaces. But no, every program can do argument delineation differently.
337.
by anarazel 5y ago
I think you need batching for the nvme doorbell alone at anything close to these kinds of rates... For some workloads it's not that hard to have that deep queues. What's harder is to know when to use them and when not. There'
338.
by anarazel 5y ago
It's worth noting that there's some batching involved, so it's not 125ns for processing one io, then again 125ns for the next. Both combining some of the work, and superscalar execution is necessary to reach this high numbers
339.
by anarazel 5y ago
That extension is not safe / correct afaict.
340.
by anarazel 5y ago
Unfortunately that didn't make it into 14, there were too many rough edges to file off.
341.
by anarazel 5y ago
It's harder to ensure that the grammar doesn't have unintended ambiguities when using a parser generator. That doesn't matter as much when "just" developing another implementation of an existing fully specced langua
342.
by anarazel 5y ago
Istm that often enough digital activity is inversely correlated with productivity. Some of my most productive days are spent between walking for a bit, staring at a paper, walking some more, staring at code,... Followed next day writing a f
343.
by anarazel 5y ago
It still increases write rate a lot over more sequential values / reduced cache hit ratio. With sequential-ish values indexed by something like b-trees the same index pages get modified over and over again because new table rows will b
344.
by anarazel 5y ago
For cases where one sensibly used uuids, I don't see natural keys being an alternative. What's e.g. the natural key of an order reference that should be accessible without auth, when the key shouldn't allow enumeration and th
345.
by anarazel 5y ago
> 1. Postgres doesn't really didn't want to be statically compiled, according to [1]. Right. There's a lot of features that'll flat out not work if you somehow compile it statically. I don't think it's a use
346.
by anarazel 5y ago
> But PostgreSQL users have told me it doesn't really matter. Those users were very wrong, unless they explicitly only talked about the case where the uuids are not indexed.
347.
by anarazel 5y ago
PostgreSQL however is not: https://www.postgresql.org/about/licence/
348.
by anarazel 5y ago
There's a decent bit of optimizations that sqlite can do by virtue of effectively being single-writer that postgres can't without compromising a lot of other workloads. That's e.g. one of (but not the only) the contributing f
349.
by anarazel 5y ago
Could you expand on the "pushing into pg" bit? Do you want to specify parameters that have a scope larger than a single statement and send the whole parameterized batch in one go?
350.
by anarazel 5y ago
> My understanding is that Redis is fast because it writes and reads from memory. Postgres is slower because it ensures writes are persisted to disk before responding (among other reasons). If you don't need transaction commits to b
351.
by anarazel 5y ago
> However, the cache effects that you mention are not syscall overhead that you could get rid of by reducing privilege crossings. They are caused by the fact that the syscall is actually executing code. That's part of it, sure. But
352.
by anarazel 5y ago
I measure ~80ns here for the most-trivial syscalls (I measured getpid() and ftruncate(-1)). However, the "real" cost often is higher, because a syscall essentially prevents out-of-order execution from hiding the cost of those cycl
353.
by anarazel 5y ago
> For sake of comparison -- does Postgres backport every security patch to every major.minor tree? Unless the security fix in question is not applicable to some branch, yes. https://www.postgresql.org/support/securit
354.
by anarazel 5y ago
It's also not rare to end up needing spinlocks within more elaborate lock implementations or within other low level primitives.
355.
by anarazel 5y ago
It depends. In a general purpose OS without scheduler trickery one would need at least some backoff & yielding syscall. And it's hugely workload dependent. But more importantly, even with kernel backed waiting (e.g. using futexes)
356.
by anarazel 5y ago
That may sometimes be true the first times you write the random data (but in my experience it's often not true even then, and only if you carefully TRIMed the whole filesystem and it was mostly empty). But on later random writes it&#x2
357.
by anarazel 5y ago
I assume one could have put a serializing instruction inside the "dangerous" path, which should then lead to the speculative execution path being rolled back before reaching the dangerous instruction. Obviously it'd also be e
358.
by anarazel 5y ago
> In flash, seeks are essentially free. That means that it does no longer matter if blocks are adjacent. > The net effect is that positioning as seen from the OS no longer matters at all from the OS layer, and that the OS layer has z
359.
by anarazel 5y ago
One consequence of that is that: > Multiple instances per device are almost a must. Isn't actually unproblematic in OLTP, because it increases the number of journal writes that need to be flushed. With a single instance group commit
360.
by anarazel 5y ago
With a lot of NVMe devices, up to medium priced server gear, the bottleneck in OLTP workloads isn't normal write latency, but slow write cache flushes. On devices with write caches one either needs to fdatasync() the journal on commit

More ›