51–60 of 95 posts
I love that infinitely nerdy stuff like this can still make it to the HN homepage (there's still hope!). Stuff like this really needs to make it into the PG tuning guide ( https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Serv... ). The only place where it will ultimately be seen by a worthwhile audience.
What are you, a school bully like the ones we see on American shows?
I love that infinitely nerdy stuff like this can still make it to the HN homepage (there's still hope!). Stuff like this really needs to make it into the PG tuning guide ( https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Serv... ). The only place where it will ultimately be seen by a worthwhile audience.
> infinitely nerdy stuff Since when is "in depth" and "technical" equivalent to "infinitely nerdy"? We're professionals using that kind of information for work, not nerds doing infinitely nerdy stuff.
I love that infinitely nerdy stuff like this can still make it to the HN homepage (there's still hope!). Stuff like this really needs to make it into the PG tuning guide ( https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Serv... ). The only place where it will ultimately be seen by a worthwhile audience.
> infinitely nerdy stuff Since when is "in depth" and "technical" equivalent to "infinitely nerdy"? We're professionals using that kind of information for work, not nerds doing infinitely nerdy stuff.
This is slightly OT, but I always wondered: what is the overhead of fetching cached stuff from the file system vs. having a built-in cache? Is there a way to circumvent going through the kernel and avoid a context switch? In other words: could a database have only minimal built-in caching and instead rely on the OS cache?
I love that infinitely nerdy stuff like this can still make it to the HN homepage (there's still hope!). Stuff like this really needs to make it into the PG tuning guide ( https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Serv... ). The only place where it will ultimately be seen by a worthwhile audience.
> infinitely nerdy stuff Since when is "in depth" and "technical" equivalent to "infinitely nerdy"? We're professionals using that kind of information for work, not nerds doing infinitely nerdy stuff.
I love that infinitely nerdy stuff like this can still make it to the HN homepage (there's still hope!). Stuff like this really needs to make it into the PG tuning guide ( https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Serv... ). The only place where it will ultimately be seen by a worthwhile audience.
> infinitely nerdy stuff Since when is "in depth" and "technical" equivalent to "infinitely nerdy"? We're professionals using that kind of information for work, not nerds doing infinitely nerdy stuff.
I've always asserted that the reason we've never seen a proper kernel bypass database engine in open source is that the Minimum Viable Product is too complex. A bare, stripped-down, low-level database engine that does full bypass of the operating system is usually at least 100kLoC of low-level C/C++, and that is before you add all the features a database user will actually want. That is a big initial investment by some people with fairly rare software design skills.
Being a user of both Linux and PostrgreSQL, I'm very interested in this issue, but I only understand some of the words... Could everybody wiser than me tell me if I should be concerned and the possible implications of these decisions? Should I invest in alternative platforms?
same here. Was a FreeBSD user, but find hard to find VM a few years ago that support FreeBSD, may switch back, if this issue is NOT addressed.
Second issue is relevant for postgresql mostly only if you use very large shared_buffers which anyway is not recommended for general workloads. Writing page that exists on disk and was not read short time before is not especially common thing to do.
Issues like the ones raised are why all sufficiently advanced database engine designs tend to evolve toward a kernel bypass architecture. From the perspective of a database engine, operating systems do a lot of "dumb" things with resource management and scheduling in ways that are essentially impossible to avoid that the database engine has enough context to do intelligently on its own. OS bypass in a database can ha…