Hacker News new | ask | show | jobs
by garyclarke27 3032 days ago
Considering that: storage costs are falling rapidly - update in place is a poor design, immutable far superior - pg is rock solid because of this architecture including DDL rollback - vacuum can recover dead space anyway! - this does seem to me to be a bit of a wasted (large) effort. Reducing size of headers and padding sounds good though. I would much rather see effort spent on incremental auto refresh of materialized views. NOT IN Foreign Keys,would also be useful to enforce XOR constraints. And Table Input parameters for Functions.
2 comments

Vacuum can't recover dead space in all cases. Consider if the dead rows are distributed throughout the table, it won't be able to reclaim it, only it can facilitate the future insertions into it. Also, the work it does to do that is many-a-times quite heavy for many workloads as it can slow down the system. I think you haven't fully looked at all the other benefits of this system which includes reducing write amplification by (a) by avoiding rewrites due to freezing, hint bits (b) making it possible to do an update that touches indexed columns without updating every index.

I think there are other benefits too in terms of just raw performance because it avoids a lot of work like HOT pruning. Yes, it instead needs to discard undo, but that is much cheaper.

In general, I think it is an overstatement to say that this is a wasted effort.

Yes I didn’t mean completely wasted, just feels to me that this requires a huge effort and is a risk to Postgres’s legendary reliability - for a relatively small gain, especially considering that ssd storage capacity will continue to increase dramatically and plummet in price. Would be better I think to prepare for new paradigm of unified immutable memory coming v soon, (Optane already shipping) which will enable Postgres to compete with ‘in memory, databases like SAP Hanna
I agree that a lot of the features you list are desirable. Like many open source projects, contributors work on features they’re interested in or paid to work on. It’s likely that you could find developers who could be motivated to realign their priorities if properly incentivized.
I agree, still amazes me how good Postgres is for free, coming from Microsoft partner world of insane SQL Enterprise per core licensing. How much incentive would you guess is required, to get auto incremental mat view refresh?
It’s likely developer dependent. You could reach out to one of the consultancies, or post an email to one of the mailing lists, though I’m not sure which one. Starting with -general would be s safe bet, and including a request for recommendation for a better list would likely get you sorted.

https://www.postgresql.org/list/

What's your use case for incremental materialized view refresh? Are you using materialized views within a single database/instance, or across links between databases?