anarazel

18 ms·

181.
by anarazel 3y ago
I did the switch from a tree walk interpreter to a VM in postgres - it did lead to substantial speedups. I've experimented with lowering into x86 "manually" as well, and it did provide gains, but the portability aspects are c
182.
by anarazel 3y ago
Why are you regularly doing vacuum full instead of just vacuuming more aggressively?
183.
by anarazel 3y ago
I think the 300% item is "Allow more efficient addition of heap and index pages". The source of the improvement is a number of related improvements around relation extension, see https://postgr.es/m/2022102902
184.
by anarazel 3y ago
Either. What the best approach is depends a bit on your needs / security model. You can e.g. something like storing the session "application user" in a configuration variable (SET myapp.rls_user =...). But if the user can inf
185.
by anarazel 3y ago
FWIW, you don't need to use database roles if you want to use RLS. You can instead have some other context indicating the current "application user" and use that in your RLS policies.
186.
by anarazel 3y ago
Yes, it's certainly easier to mitigate at a boundary that's already as costly as switching between VMs. The paper documents that disabling SMT does not entirely mitigate the problem (In 9.1). They briefly mention trying instruct
187.
by anarazel 3y ago
It only seems to document that there's group scheduling for SMT cores. But that doesn't prevent issues due to switching between customers on the same physical core, no? "It is possible, however, for two burstable performance
188.
by anarazel 3y ago
I think there's several levels. As a first step, I'd appreciate reducing the risk of javascript extracting contents from outside the browser. A second step could be to use more granular core scheduling within firefox, to prevent
189.
by anarazel 3y ago
Indeed. Making the program wait (using a barrier) after all the threads have started, I see a a substantially higher memory usage than reported by time. I only used 100k threads. For me time reports 1018376kB, but looking at /proc&#x2F
190.
by anarazel 3y ago
I don't think the 8KB calculation is quite right - there are allocations in the kernel for every thread as well, and I don't think that'll be accounted for by /use/bin/time.
191.
by anarazel 3y ago
What does that chicken bit do?
192.
by anarazel 3y ago
I wish Firefox would use PR_SCHED_CORE to reduce the likelihood of such leakage...
193.
by anarazel 3y ago
It was more a rethorical doubting because I did not want to look the standard up on my phone....
194.
by anarazel 3y ago
That assumes the specified allocator actually controls all allocations - somewhat doubtful across all platforms as things like dl_iterate_phdr() IIRC allocate memory (and take locks). And there's a lot more to writing signal safe code
195.
by anarazel 3y ago
The crashing thread might hold a lock in the memory allocator - which could either self deadlock when saving the stack trace (which certainly seems to do memory allocation and thus isn't a-signal safe), or could deadlock with the crash
196.
by anarazel 3y ago
This does not even remotely look to be signal safe to me?
197.
by anarazel 3y ago
Ime the execinfo.h backtraces are unfortunately not that useful in practice, due to being unable to resolve symbol names of static functions. But FWIW, you can use it for async signals with the _fd variant.
198.
by anarazel 3y ago
FWIW, the last time I measured the string handling part was far slower than the timezone conversion when loading timestamptz data in postgres.
199.
by anarazel 3y ago
> > Of course it's even better to not block at all... > Out of curiosity, is that something you ever want/hope to achieve in PostgreSQL? Many high-performance systems use this model, but switching a synchronous system in
200.
by anarazel 3y ago
Yea. Just about none of them could be optimized to constants because, uh, they're not constant. We're not perfect, but we do add const etc to TU level statics/globals that are actually read only. And if they are actually read
201.
by anarazel 3y ago
> io_uring is designed for systems that have a thread and ring per core That's not needed to benefit from io_uring > for you to give it a bunch of IO to do at once (batches and chains), and your threads to do other work in the me
202.
by anarazel 3y ago
> That said, I think there have been efforts to use io_uring on Linux. I'm not sure how that would work with the process per connection model. Haven't been following it... There's some minor details that are easier with th
203.
by anarazel 3y ago
Imo unikernels are a complicated solution in search of a problem, which turns out to not exist. There certainly are times OSs get in the way. But it's hard enough to write a good database, we don't need to maintain a third of an O
204.
by anarazel 3y ago
The TLB issue are more a hardware issue than a software/OS one. To my knowledge neither x86 nor arm provide a way to partially share TLB contents between processes/entities. Tlb entries can be tagged with a process context ident
205.
by anarazel 3y ago
Not who you asked, but: He is a longtime contributor who has written/resigned important parts of postgres (WAL format, concurrent WAL insertion, 2PC support, parts of SSI support, much more). And he is just a nice person to work with.
206.
by anarazel 3y ago
What makes you think that it will require that many changes? There will be some widespread mechanical changes (which can be verified to be complete with a bit of low level work, like a script using objdump/nm to look for non-TLS mutabl
207.
by anarazel 3y ago
We do fix crashes etc, even if the postgres manages to restart. I think the post upthread references an out-of-core extension we don't control, which in turn depends on many external libraries it doesn't control either...
208.
by anarazel 3y ago
The issue is costlier (runtime, complexity, memory) resource sharing, not the cost of the fork itself. Pre-forking isn't going to help with any of that.
209.
by anarazel 3y ago
Hard to believe that would provide any benefit without also causing massive slowdowns.
210.
by anarazel 3y ago
I know that at least people from EDB (Robert) and Microsoft (Thomas, me) are quite interested in eventually making this transition, it's not just Heikki. Personally I won't have a lot of cycles for the next release or two, but aft

More ›