JimNasby

More than 4 GW of capacity has gone offline in the last few minutes, based on http://www.ercot.com/content/cdr/html/real_time_system_condi.... A significant chunk of load was shed as well. Frequency is swinging pretty wildly.

The grid has basically zero capability to change the voltage; frequency is all that matters. Frequency is so low that in the past hour any power line time base has fallen over 5.5 seconds behind. That’s a massive drop in frequency.

Out of curiosity, is it inheritance you like, or just the partitioning aspect of it?

I've actually used inheritance far more than partitioning, but I know of others that would love to see inheritance die.

Something that might be very interesting would be combining https://www.torodb.com/ with Timescale. ToroDB is database agnostic (though they prefer Postgres). If you extracted the appropriate keys (including the timestamp) out I expect the combination would be very powerful.

Not sure what you're trying to say about "requires no extensions"; Timescale is an extension that doesn't modify Postgres itself, similar to Citus, and very different from XL/XC, GreenPlum, or EnterpriseDB's proprietary offerings.

FWIW, I got the impression that they didn't truncate the table, but just forced an update to it's relfrozenxid to advance the freeze age and allow the database to restart. That means there's a risk that rows that were currently visible would suddenly vanish as the XID advanced and their xmin became "the future". Eventually record of those commits would vanish and presumably the rows would then get removed (though I'm not sure on that without checking the code).

I think the real takeaway here is that any part of your underlying technology that you don't thoroughly understand puts you at risk, and that risk goes up significantly in a large volume environment. It's frequently not possible to have experts on-hand for everything, but you need to make sure you have them for your critical stuff. They don't necessarily have to be on your payroll either; really good consulting companies can do a lot for you as well. (Disclosure: I'm a partner at a consulting company).

When it comes to Postgres and data, I'll just say what I've been saying for ~20 years:

"All databases suck, each one just sucks differently."

You need to monitor how close you are to a wraparound. https://bucardo.org/check_postgres/check_postgres.pl.html#tx... is one way you could do that.