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

31–40 of 89 posts

Re: PostgreSQL 16

#31

Post by ellisv »

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

I’m not familiar with the VACUUM changes but the situation you’re describing suggests something is wrong with the table definition or database configuration.

Re: PostgreSQL 16

#32

Post by brianwawok »

ellisv wrote: post #31
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).

I’m not familiar with the VACUUM changes but the situation you’re describing suggests something is wrong with the table definition or database configuration.

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.

Re: PostgreSQL 16

#33

Post by theandrewbailey »

This is great!

But I just installed the latest Debian with Postgres 15, haha. I don't even think I'm using any features past 11 (websearch_to_tsquery), so I'll need to research anything new that might be useful to me.

Re: PostgreSQL 16

#34

Post by salojoo »

brianwawok wrote: post #32
ellisv wrote: post #31

Earlier quoted context omitted.

I’m not familiar with the VACUUM changes but the situation you’re describing suggests something is wrong with the table definition or database configuration.

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?

Re: PostgreSQL 16

#35

Post by ellisv »

brianwawok wrote: post #32
ellisv wrote: post #31

Earlier quoted context omitted.

I’m not familiar with the VACUUM changes but the situation you’re describing suggests something is wrong with the table definition or database configuration.

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?

Re: PostgreSQL 16

#36

Post by lfittl »

dekobon wrote: post #24
simonw wrote: 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?

You can see a break-down of the core team and major contributors here, as well as their current company affiliation: https://www.postgresql.org/community/contributors/

(and as noted in the other comment, whilst EDB certainly makes important contributions, they are one of many)

Re: PostgreSQL 16

#39

Post by eestrada »

clarkdave wrote: post #20
riku_iki wrote: post #19

Earlier quoted context omitted.

They significantly increased major versions frequency, transition from 9 to 10 took 7 years, and now they release major version every year.

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.

Re: PostgreSQL 16

#40

Post by bdcravens »

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.
Post reply on HN