Live data from Hacker News

PostgreSQL 16

postgresql.org

21–30 of 89 posts

Re: PostgreSQL 16

#21
post #17

Earlier quoted context omitted.

[flagged]

if they're getting more than $200 then it's already way more money than I think. It's true that there is some money (after all, there is pgcon); and it's true that some people are paid to work on postgresql. However: it's additionally true that there are many volunteers, and that it's free for us to use, modify, hack on and so forth. coordinating that effort must be absolutely herculean.

> It's true that there is some money

This is such a misleading understatement. There is a ton of money. Many of the core Postgres contributors have fully remunerated employment where much of their time is dedicated to postgresql development. This is fully deserved and appropriate - but Tom Lane, et al are not working on this for free (that they still might if they had to do is another thing) but these are all highly compensated contributors. The total payroll spend on postgresql is distributed and decentralized but it is clearly in the multimillions.

People should not be mislead about true costs regardless how they’re meted out.

Re: PostgreSQL 16

#22

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..…

PostgreSQL is also one of the most impressive projects out there in terms of being community maintained, as opposed to many large FOSS projects which have some kind of corporate backing employing the majority of the core team.

Re: PostgreSQL 16

#23

can anyone point to the COPY FROM improvements mentioned that can result in up to 300% performance improvements is it the line in the release notes about "ASCII string detection"?

I think the 300% item is "Allow more efficient addition of heap and index pages". The source of the improvement is a number of related improvements around relation extension, see https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.a...

Re: PostgreSQL 16

#24
post #22

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..…

PostgreSQL is also one of the most impressive projects out there in terms of being community maintained, as opposed to many large FOSS projects which have some kind of corporate backing employing the majority of the core team.

Isn't the good part of the core team part of EnterpriseDB?

Re: PostgreSQL 16

#26
post #11
post #4

Do I still have to use pg_upgrade when I'm just upgrading from RC-1?

git diff REL_16_RC1..REL_16_0 doesn't show any changes that would require a pg_upgrade (at least from my read), so you should be able to upgrade without it.

I just tested, I had to use pg_upgrade.

Error message: The database cluster was initialized with CATALOG_VERSION_NO 202306141, but the server was compiled with CATALOG_VERSION_NO 202307071.

Re: PostgreSQL 16

#27
post #26
post #11

Earlier quoted context omitted.

git diff REL_16_RC1..REL_16_0 doesn't show any changes that would require a pg_upgrade (at least from my read), so you should be able to upgrade without it.

I just tested, I had to use pg_upgrade. Error message: The database cluster was initialized with CATALOG_VERSION_NO 202306141, but the server was compiled with CATALOG_VERSION_NO 202307071.

You might just need to run:

    alter database mystuff refresh collation version;

Re: PostgreSQL 16

#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).

Re: PostgreSQL 16

#30
post #24
post #22

Earlier quoted context omitted.

PostgreSQL is also one of the most impressive projects out there in terms of being community maintained, as opposed to many large FOSS projects which have some kind of corporate backing employing the majority of the core team.

Isn't the good part of the core team part of EnterpriseDB?

3 of 7 work at EDB, and the core team doesn’t drive the project roadmap. And EDB hackers fail to get patches in all the time, just like everyone else :)
Post reply on HN