Viewing profile — rastignack
rastignack
HN member- Joined
- Mon, Jan 03, 2022, 9:58 PM UTC
- HN karma
- 358
- Public activity
- 178 items
- HN profile
- View on Hacker News ↗
About rastignack
No profile information was provided.
Recent public activity
-
comment
Comment #49224749
Yes for this particular use case it might help (no per-application aggregated temp file limit though). Also my grid workloads generate thousands of threads running queries with lot…
-
comment
Comment #49220577
Interesting. It would need some work to handle all the workloads I’ve faced where you have two applications with different priorities (ie oltp or grid workloads and analytics). In …
-
comment
Comment #49212770
I would be interested about a more detailed architecture overview of the io scheduler (like this: https://www.scylladb.com/2021/04/06/scyllas-new-io-scheduler... ) and the thread s…
-
comment
Comment #48830519
And why it should be done upstream with a thread pool model and an internal scheduler as MS SQL server does.
-
comment
Comment #48607767
The thing is you are going to be comoditized on this too. And it’s going to be faster to migrate off your database with AI. You are going to need to have a plan.
-
comment
Comment #48415374
I hope it could be used in the future to export pg_dump formated exports to s3. One would be able to trigger maintenance jobs via simple lambda functions whose duration is capped.
-
comment
Comment #48344207
And if you write to a bytes buffer?
-
comment
Comment #47819871
Just monitor it and you’re done. I’ve delivered and maintained hundreds of pg instances and never faced this issue. There is so much literature about it that at some point no one e…
-
comment
Comment #45924449
I have tens of clusters to maintain. Quite an advertisement for ECS!
-
comment
Comment #45691686
Is there now a way to avoid double buffering and use direct IO in postgresql ? Has anybody seriously benchmarked this ? I don’t think io uring would make a difference with this set…
-
comment
Comment #45203525
Remember to turn off autoplay on Twitter.
-
comment
Comment #45083324
How about acknowledging you’ve been too sharp with words, apologizing, and attempting to move forward ? I know other people in the kernel do the same mistake as you frequently do o…
-
comment
Comment #44891920
Some distributions do release hotfixes before they reach mainline kernel. If you expect end users to compile Linus’ kernel head, why couldn’t they compile your branch though ? They…
-
comment
Comment #44890251
Maybe then you should have considered this file system as truly experimental and expected your end users to make frequent backups. And advertise it as such. You could also have som…
-
comment
Comment #44889440
Maybe the FS was upstreamed too soon, causing your development velocity and the high expectations you have for your end users to be at odd with the well entrenched workflows of Lin…
-
comment
Comment #44872873
Mr Torvalds has already said “we’re done”. And Mr Overstreet’s behavior is still unprofessional. I think this thread is really insightful to teach highly skilled individuals that p…
- story
-
comment
Comment #44725775
One does not justify a wrong by another wrong. It’s a classic sophism. I do not live in the US but did see some truly shocking and illegal behaviors at gay prides and drag themed e…
-
comment
Comment #44719562
[flagged]
-
comment
Comment #44700230
Nowadays a lot of people script in python
-
comment
Comment #44622649
I’ll finish it this summer, hopefully.
-
comment
Comment #44622139
I don’t think channels and goroutines suck. For example their usage in golang’s ssh server implementation is eminently readable. And performant enough. Engineers ship with them, an…
-
comment
Comment #44550893
I wrote a simple ssh server in zig to learn the language in my spare time. The new design makes the event loop / io much easier to reason about. Thanks Andy
- story
-
comment
Comment #44293030
Would the sync.Pool trick mentionned here: https://hypermode.com/blog/introducing-ristretto-high-perf-g... help ? It’s lossy but might be a good compromise.