PostgreSQL pain points

Posted Mar 26, 2014 9:02 UTC (Wed) by iq-0 (subscriber, #36655)
In reply to: PostgreSQL pain points by kev009
Parent article: PostgreSQL pain points

My guess would be that that's because it's a very tricky topic. I think everybody knows that something should be fixed there, but that nobody has come up with a possible fix that wouldn't cause major regressions in other workloads.

But I think anybody would agree that a mere fsync() (or similar operation) should cause this extreme form of starvation.

I'd guess this is also similar to stalls seen when writing to a slow USB device (those eventually turn into forced syncs because of dirty limits induced forced writeback and case similar starvation). But I don't know if those code paths are similar enough in that fixing one will also directly benefit the other.

PostgreSQL pain points

Posted Mar 26, 2014 16:35 UTC (Wed) by Lennie (subscriber, #49641) [Link]

"I'd guess this is also similar to stalls seen when writing to a slow USB device (those eventually turn into forced syncs because of dirty limits induced forced writeback and case similar starvation). But I don't know if those code paths are similar enough in that fixing one will also directly benefit the other."

I've seen people suggest this might be solved by the Multi-Queue Block layer (blk-mq) as merged in 3.13, does anyone know if this is true ?