anarazel

5 ms·

1.
by anarazel 28d ago
Fwiw, I, as someone who has worked on Postgres for a long time, also find it quite tiresome. Like there's plenty stuff I wouldn't use Postgres for, and I can probably get get more out of it than most.
2.
by anarazel 2mo ago
Small addendum: Unless the whole table is in that state (or even newer), vacuum shouldn't do a full table scan, but only process not yet vacuumed parts of the table. There are some exceptions to that (evenly randomly updated tables, ve
3.
by anarazel 3mo ago
> Well also I know Postgres UNIQUE indexes provide additional locking. Like you can do an INSERT... WHERE NOT EXISTS or INSERT... ON CONFLICT that is guaranteed to succeed. That's true only for the latter (and even then only at a is
4.
by anarazel 3mo ago
Indeed. Not enough coffee, apparently.
5.
by anarazel 3mo ago
There's a bunch of nastiness around that too. If you have e.g. library state that assumes the fd still works you can get her very confusing bugs once another file is opened into that fd number...
6.
by anarazel 3mo ago
It is somewhat interesting that the most widely used "big" OS that doesn't use fork, i.e. Windows, has dog slow process creation... I agree that there should be non-fork primitives, I'm just not that sure that performanc
7.
by anarazel 4mo ago
> Use of the "h" register slices (bits 8..15) by compilers is thankfully pretty rare -- otherwise this would have been noticed much sooner! It's actually pretty easy to get compilers to use those, you mainly need a bunch o
8.
by anarazel 4mo ago
> It's not the default (read committed is) and I never saw serializable being set in actual production systems. It's not the common mode of deployment, but it's definitely in prod use. > You can do it, but then you have
9.
by anarazel 4mo ago
The GOT has to be initially writable regardless of ifunc, even with relro, to apply relocations.
10.
by anarazel 5mo ago
> It is a crime that postgres isn't able to allocate with 1GB huge pages by changing a config parameter in 2026 It is able to? Configure huge_page_size=1GB? Support for 2MB pages was added in 2014, for larger pages 2020. Edit: year
11.
by anarazel 5mo ago
I stopped drinking a few years back, after some (unrelated) health stuff. I don't miss wine, beer, that stopped - like for the author - after a relatively short amount of time. But interestingly I still really miss the feeling of a goo
12.
by anarazel 5mo ago
Ability to trivially use custom VM images was quite nice. The amount of CI time spent installing dependencies or copying a cache of installed stuff is nontrivial. Particularly for Windows the time difference is often very substantial. But e
13.
by anarazel 5mo ago
Weirdly enough, I loved coffee from the first time I tried it, at maybe 13. Even though, looking back, it must have been terrible coffee, it was at something vaguely model UN like thing our entire class went to in an overnight trip. Obvious
14.
by anarazel 5mo ago
> ... so that leaves me confused. My understanding is that the regression is triggered with the 7.0+ kernel and can be mitigated with huge pages turned on. It gets a bit worse with preempt_lazy - for me just 15% percent or so - because t
15.
by anarazel 5mo ago
The contention does exist in older kernels and is quite substantial.
16.
by anarazel 5mo ago
> That 64-bit atomic in the buffer head with flags, a spinlock, and refcounts all jammed into it is nasty. Turns out to be pretty crucial for performance though... Not manipulating them with a single atomic leads to way way worse perform
17.
by anarazel 5mo ago
> > On x86 a spinlock release doesn't need a memory barrier (unless you do insane things) / lock prefix, but a futex based lock does (because you otherwise may not realize you need to futex wake). > Now you've gotten
18.
by anarazel 5mo ago
Addendum big enough to warrant a separate post: The fact the contention is a spinlock, rather than a futex is unrelated to the "regression". A quick hack shows the contended performance to be nearly indistinguishable with a futex
19.
by anarazel 5mo ago
I really dislike the use of spinlocks in postgres (and have been replacing a lot of uses over time), but it's not always easy to replace them from a performance angle. On x86 a spinlock release doesn't need a memory barrier (unles
20.
by anarazel 5mo ago
I don't fully know, but I suspect it's just that due to the minor faults and tlb misses there is terrible contention with the spinlock, regardless of the PREEMPT_LAZY when using 4k pages (that easily reproducible). Which is then m
21.
by anarazel 6mo ago
Yes, I did reproduce it (to a much smaller degree, but it's just a 48c/96t machine). But it's an absurd workload in an insane configuration. Not using huge pages hurts way more than the regression due to PREEMPT_LAZY does. Wi
22.
by anarazel 6mo ago
Cross building of possible, but it's rather useful to be able to test the software you just built... And often enough, tests take more resources than the build.
23.
by anarazel 7mo ago
Just German, not European, but still a start: https://en.wikipedia.org/wiki/Sovereign_Tech_Agency
24.
by anarazel 7mo ago
It's very heavily dependent on what your processes are doing. I've seen extreme cases where the gains of pinning were large (well over 2x when cooperative tasks were pinned to the same core), but thats primarily about preventing t
25.
by anarazel 8mo ago
> PostgreSQL shares other caches between processes so they probably could have a global plan cache if they wanted. I wonder why they don’t though. > One possible reason is that the planner configuration can be different per connection
26.
by anarazel 8mo ago
I would hope it's at least 3-4 orders of magnitude slower than a "traditional QR library". It'd be quite the indictment for such libraries, if not.
27.
by anarazel 8mo ago
I know, but even if it's not breaking promises, the constant stream of changes still makes it still rather painful to utilize LLVM. Not helped by the fact that unless you embed LLVM you have to deal with a lot of different LLVM version
28.
by anarazel 8mo ago
FWIW, the article says "Frontends are somewhat insulated from this because they can use the largely stable C API." but that's not been my/our experience. There are parts of the API that are somewhat stable, but other par
29.
by anarazel 9mo ago
I'm certainly very biased (having worked on postgres for way too long), so it's entirely plausible that I've over-observed and over-analyzed the criticism, leading to my description. > I (we?) think Postgres is incredibly
30.
by anarazel 9mo ago
> First, although I work at Oxide, please don't think I speak for Oxide. None of this happened at Oxide. It informed some of the choices we made at Oxide and we've talked about that publicly. I try to remember to include the ca

More ›