Hacker News Reader

Comment by deepsun | Hacker News Reader

> Andres Freund, like a number of other PostgreSQL developers, has acknowledged that DIO is the best long-term solution. But he also noted that getting there is "a metric ton of work" that isn't going to happen anytime soon.

No, that is a "recipe for disaster", as they say. Not doing something that everyone acknowledging as important, because that's a "lot of work" is what makes projects a mess. I've seen that many times on various projects.

View on HN

Uh. We've five years of old versions to support. We're not going to backpatch the invasive stuff necessary to make DIO performant.

And it'd not be the default anyway, as it requires more tuning.

We are working on getting there.

I don't see how you could write your post unless you're so naive you think there are no trade-offs.

You sound like a Dilbert manager's "I don't care, just have it on my desk at all costs by Friday."

That is not sound engineering.

Diving in and quickly doing something complicated without a lot of careful consideration and testing is a recipe for disaster. Especially when there may be a simpler way of accomplishing the same goals, that just isn't available yet (be it future APIs, or some better way that no one has thought of yet).

What is DIO?

Direct input/output; the software performs write(2) system calls directly and does its own input/output buffering and scheduling, bypassing the operating system and filesystem driver buffering. For this to be effective and function correctly, the filesystem driver must support mounting in direct input/output mode, or raw character devices must be presented to the software in question. Note that presenting raw block devices bypasses filesystem driver’s buffering, but does not bypass operating system (kernel) buffering, hence character devices must be used to bypass both. Software which uses raw devices usually has sophisticated input/output scheduling and buffering optimally tuned for its use case.

Reply on news.ycombinator.com