Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 16

postgresql.org

Post reply on HN
Print view View original

81–89 of 89 posts

Re: PostgreSQL 16

#81

Post by pas »

zozbot234 wrote: post #18
pas wrote: post #13

Earlier quoted context omitted.

schools either never worked or stopped working. after all, look, almost all the people who went to school don't give a fuck about underperforming underfunded school systems. (or healthcare or ... or if they care they are ignorant and clueless about what to do with the problem, and easily fell prey to political dogma of some group.) it's simply time to stop worrying about it.

School systems are not underfunded. They're underperforming despite being overly funded. We're throwing good money after bad.

well, real value of salaries of teachers are plummeting. of course the same thing happens in other hard-to-scale demand-for-quality service sectors (like healthcare, but also construction work, where standards simply increased, which have a lot of associated labor, which now cost a lot more due to multiple factors, eg. less immigration, shrinking of the active population - end of the positive effects of the baby boom demographic boost, of course there's also the inescapable Baumol effect).

Re: PostgreSQL 16

#82

Post by pas »

dijit wrote: post #16
pas wrote: post #13

Earlier quoted context omitted.

schools either never worked or stopped working. after all, look, almost all the people who went to school don't give a fuck about underperforming underfunded school systems. (or healthcare or ... or if they care they are ignorant and clueless about what to do with the problem, and easily fell prey to political dogma of some group.) it's simply time to stop worrying about it.

The people underfunding our schools had their private schooling paid for by virtue of being unconscionably wealthy. The more you realise what has happened the more maddeningly upset you will get, so it's best not to think about it. Sufficed to say: you're wrong, additionally: dead wrong and it's not relevant for a topic about databases.

nah, there's a broad consensus of US (and alas also in most countries') population of not wanting to pay for "externalities", they want cheap gas and cheap labor, cultural homogeneity, and so on.

if a few thousand private school darlings can bamboozle hundreds of millions for decades, then the problem is not just with them.

of course it's cultural and it's due to the very strong biases of the last who-knows-how-many centuries.

> and it's not relevant for a topic about databases

it's very relevant for the whole concept of FOSS "moon landings" and the commons

Re: PostgreSQL 16

#83

Post by epcoa »

bdcravens wrote: post #40
data_ders wrote: post #7

anytime a huge multi-decades-old FOSS project lands a milestone, I can't help but equate it to something like a moon landing. So much (unpaid) work and thought goes into stewarding open software. Kudos to the whole team. Software infra is just as important as bridges and roads -- here's hoping we can fund it at least as well, for humanity's sake. [1] [1]: https://www.fordfoundation.org/work/learning/research-report..…

Isn't the work in large projects often done by those paid by their employers on "company time"? For instance Bruce Momjian by EDB.

Yes, and Andres (literally the “main hat” they wear at Microsoft is work on PostgreSQL, and Tom, etc. I don’t understand why pointing out what should be obvious gets people to lose their mind here and is such a controversy. PostgreSQL like Linux is a massively commercially sponsored project - that there are some volunteers doesn’t change that.

I used to be paid full time to mostly work on a Linux kernel subsystem. This discussion is silly.

Re: PostgreSQL 16

#84

Post by esaym »

guenthert wrote: post #77
esaym wrote: post #63

Earlier quoted context omitted.

I probably meant to say "synchronous_commit", which is how data is written to disk from the WAL. If you want full data guarantees, with regular hard drives, you'd be looking at less than 200 transactions per second. You set synchronous_commit to off, and suddenly you can do 10k transactions per second. You can tune when the WAL gets flushed to disk based on time and/or size. So you can set the amount of recent data l…

> If you want full data guarantees, with regular hard drives, you'd be looking at less than 200 transactions per second. That sounds like an anecdote from the time before SSDs. > "setting this parameter to off does not create any risk of database inconsistency: an operating system or database crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as…

> That sounds like an anecdote from the time before SSDs.

Yes, I stated "regular hard drives" :)

Re: PostgreSQL 16

#85

Post by riku_iki »

eestrada wrote: post #39
clarkdave wrote: post #20

Earlier quoted context omitted.

They just changed the versioning scheme; it used to be that e.g. 9.3 -> 9.4 was a major version (i.e. can't be upgraded in-place). Starting with PG 10 major versions are now 10 -> 11, etc. I don't believe the major release cadence itself changed that much

It seems like they fell more inline with Semantic Versioning when that format came in vogue. Semantic Versioning is what most devs expect now; it makes sense to communicate the version in a format that has a broadly understood meaning for devs.

I think there is no semantic versioning anymore, they just release one major number version every year, regardless how large and backward compatible changes are there.

Re: PostgreSQL 16

#86

Post by reactor »

brianwawok wrote: post #29

Anyone know more about the "vacuum" improvements? To make my database fast, I often have to do a vacuum full on some key tables. Which is basically a freeze all access to the table, and copy byte by byte to a new physical file. So as your data size doubles, the vacuum full time doubles. Have a table that is so big I basically can't vacuum full it anymore (in an acceptable amount of downtime).

As other commenter mentioned, you can use pg_repack. We also had similar issue and we configured it to run every month and it works flawlessly.

Re: PostgreSQL 16

#87

Post by brianwawok »

reactor wrote: post #86
brianwawok wrote: post #29

Anyone know more about the "vacuum" improvements? To make my database fast, I often have to do a vacuum full on some key tables. Which is basically a freeze all access to the table, and copy byte by byte to a new physical file. So as your data size doubles, the vacuum full time doubles. Have a table that is so big I basically can't vacuum full it anymore (in an acceptable amount of downtime).

As other commenter mentioned, you can use pg_repack. We also had similar issue and we configured it to run every month and it works flawlessly.

Oh interesting. In my case I am on google hosted postgres, so I’ll need to double check it works there:

Re: PostgreSQL 16

#88

Post by brianwawok »

salojoo wrote: post #34
brianwawok wrote: post #32

Earlier quoted context omitted.

How do you figure? Postgres docs are quite clear. Table space is not reclaimed without a vacuum full. So delete a column in a big table? you are storing that data forever.

Have you tried pg_repack?

No but someone else suggested it. If it works on google cloud I might be in business.

Re: PostgreSQL 16

#89

Post by brianwawok »

ellisv wrote: post #35
brianwawok wrote: post #32

Earlier quoted context omitted.

How do you figure? Postgres docs are quite clear. Table space is not reclaimed without a vacuum full. So delete a column in a big table? you are storing that data forever.

If rewriting the table is part of a regular workflow, then database configuration can play a significant role in its performance. However I still contend that rewriting tables regularly is an anti pattern. Are you able to partition any of your tables so that you can VACUUM FULL the partitions individually?

Yah partition is my eventual end goal. It’s getting less and less awkward with each PG version to partition. It’s still a little awkward in Django. But heck, I haven’t tried it in a year, maybe worth another shot.
Post reply on HN