
PostgreSQL 13 Beta 1 Released - jkatz05
https://www.postgresql.org/about/news/2040/
======
philliphaydon
The only thing I want for PostgreSQL is a better backup/restore. SqlServer is
so easy. You backup a database and restore it and never have any issues. You
connect the users in the instance to the users in the database and away you
go.

PostgreSQL will allow a backup and then epic fail on the restore if you don’t
have users and roles etc pre defined.

It’s the hardest thing to achieve in PostgreSQL.

~~~
Tostino
Yeah, that's because you're using the wrong tool for the job. You are using
pg_dump on a single database, or set of databases. Use pg_dumpall:
[https://www.postgresql.org/docs/current/app-pg-
dumpall.html](https://www.postgresql.org/docs/current/app-pg-dumpall.html)

For an actual backup solution, not one off stuff, use a tool like pgbackrest.
It's just way better.

~~~
philliphaydon
I’m pretty sure I’ve tried dumpall before but honestly cannot remember but
you’re right do use dump.

I’ll give dumpall a go today. I do still feel this could be improved in
PostgreSQL because there’s sooo many blog posts who suggest dump and none of
them work.

------
Tostino
Super excited for the improvements to btree indexes, that is some interesting
work and very impressive results. The improvements to pg_stat_statements will
be very welcome too!

------
jacobkg
As someone still on Postgres 9.6, does anyone have advice on how to make the
business case for upgrading to 10, 11, or 12? I want to upgrade but I have a
hard time articulating the benefits against the costs of downtime and risk

~~~
aeyes
With the upgrade from 9.6 to 10 we improved performance by 20% without doing
any other changes. From 10 to 11 it was pretty similar, saw a 15-20%
performance increase.

We haven't made the jump to 12 yet, we expect overall performance to be lower
but disk I/O to be improved.

If performance doesn't matter and you don't need any of the new features
you'll have a hard time finding reasons to upgrade. I consider 9.6 to be very
stable.

~~~
Tostino
While it may be very stable, the business case for upgrading sooner rather
than later is not being behind the 8-ball when 9.6 EOL comes in a year.

------
kcolford
Am I the only one eagerly waiting on postgres to transition away from the
process per connection model? It seems like that is the only glaring con for
postgres compared to SQL server. This would really put the nail in coffin for
MySQL and other alternatives.

~~~
fabian2k
There is a proposed change that improves connection scaling signficantly:

[https://www.postgresql.org/message-
id/flat/20200301083601.ew...](https://www.postgresql.org/message-
id/flat/20200301083601.ews6hz5dduc3w2se%40alap3.anarazel.de)

This should be either in Postgres 13 or 14, not sure how they decided in the
end.

~~~
ksec
Strange, they really wanted it for 13 and allowed it to be committed post
feature freeze, but then all discussions stopped after April. And I couldn't
find anything else in the mailing list.

~~~
pgaddict
There was a long discussion about multiple patches that "almost made it" on an
internal release list. Ultimately, the conclusion was not to push them after
the code freeze date (which was already extended by a week).

Obviously, it'd be great to get those patches in, but there's always the risk
of pushing something that may not be quite ready yet, did not go through
sufficient review etc. Which might disrupt the whole release schedule, make
the stabilization phase longer, etc. And all the lockdowns around the world
just amplify the risk. There's also the question whether it's worth breaking
the rules the project adopted over the years. Considering all this, it
probably makes sense to leave this for v14 ...

But yeah, it'd be great to have this in v13, had it been ready before the code
freeze.

~~~
ksec
Thanks. At least we know it should be coming in PG 14. Hopefully Zheap too.

------
garyclarke27
I love Postgres, it’s an incredible piece of software, I have to say though,
this is the least exciting update I’ve seen, in the last 10 years that I’ve
been using it. Probably because it’s now so capable, the only major missing
feature for me is, automatic incremental update to materialized views, one of
the few important remaining advantages that Oracle has over Postgres.

~~~
Tostino
This release had quite a few patches that just weren't quite ready to go out
yet, so were not included.

There was some work done which reduces the per-connection overhead and allows
many many more direct PG connections before performance degrades, while
increasing overall performance with high connection counts by a ton...but it
just wasn't quite ready and missed the deadline by a little.

The memory based stats collector is another patch in the same vein, where it
wasn't quite ready for 13.

That said, many of these features are quite impressive and will offer nice
wins for many workloads, incremental sorting is very cool, as is the memory
bound hash aggregation.

I'm with you on automatically updated materialized views, it's been something
i've needed and been waiting for a long while now, and I am hoping it gets
more focus. The current patch-set being worked on for it seems to have quite a
few limitations.

------
cryptonector
> PostgreSQL 13 continues to improve operability on Windows, as now users who
> run PostgreSQL on Windows now have the option to connect over UNIX domain
> sockets.

I'm curious about this!

~~~
ComputerGuru
Windows 10 brought in support for AF_UNIX:
[https://devblogs.microsoft.com/commandline/af_unix-comes-
to-...](https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/)

~~~
cryptonector
Nice! Thanks for the link!

------
jabl
Zheap didn't make it?

~~~
Tostino
Not yet, they have done much work on the pluggable storage API, but I haven't
seen much discussion on the mailing list at all about zheap in a while but
work seems to continue with it.

~~~
jfbaro
Pluggable storage would potentially be useful for YugaByte as well. PostgreSQL
will see even more innovation in the years to come. Well done PostgreSQL
community.

------
arusahni
Still hoping for a transaction manager so I can implement 2PC using
postgres_fdw.

~~~
skyde
I don't know your use-case exactly but every distributed system engineer
should know that 2PC is extremely dangerous.

It is a blocking protocol, This mean if the coordinator crash , some
participants will never resolve their transactions.

After a participant has sent an agreement message to the coordinator, it will
completely block until a commit or rollback is received from the coordinator
but this will never happen.

~~~
arusahni
Thanks for the warning - I agree that there are dragons. I have some well-
constrained use-cases, and would love to obviate the need for "yet another
microservice."

------
rnikander
I find it frustrating that stored procedures can't start and stop
transactions. Without that ability, you can't really move application logic
into the database.

[edit: Doh, I'm wrong. Sorry. I'll leave the comment here.]

~~~
petereisentraut
Sure they can. See example here:
[https://www.postgresql.org/docs/current/plpgsql-
transactions...](https://www.postgresql.org/docs/current/plpgsql-
transactions.html)

