21–30 of 62 posts
- pg_hba.conf and pg_ident.conf can include other files
- Logical replication apply can use non-PK btree indexes
- Integer literals in non-decimal bases
- Underscores in numeric literals
- Subqueries in the FROM clause can omit aliases
- Addition and subtraction of timestamptz values
- pg_upgrade can override new cluster's locale and encoding
Earlier quoted context omitted.
Could you elaborate on the load balancing? Is this a replacement for PG bouncer and similar?
IMO the biggest reason folks use pgbouncer is not for load balancing (which it can do, -ish) but instead for connection pooling. Postgres connections are expensive for the db server (one process per connection not one thread) so if you have say thousands of web application pods you need to use pgbouncer or similar as a proxy to multiplex those thousands of connections down onto a more manageable number (~200). So no,…
[flagged]
It can be. We still running PG11 and 13 in production. Not obligated to upgrade - especially when the software is rock solid.
If I was running PG 11 in production, I'd be looking to upgrade sooner rather than later. Being on older-but-stable versions is good risk management, being on end-of-life version is not.
Earlier quoted context omitted.
It can be. We still running PG11 and 13 in production. Not obligated to upgrade - especially when the software is rock solid.
PG 11 is end-of-life, right? So you won't be getting new security updates. What's worse, libraries will stop supporting it over time, so you'll find it difficult to stay up to date in other places in your stack. If I was running PG 11 in production, I'd be looking to upgrade sooner rather than later. Being on older-but-stable versions is good risk management, being on end-of-life version is not.
Not quite yet https://www.postgresql.org/support/versioning/ - the final release will be November 9, 2023.
Earlier quoted context omitted.
It can be. We still running PG11 and 13 in production. Not obligated to upgrade - especially when the software is rock solid.
PG 11 is end-of-life, right? So you won't be getting new security updates. What's worse, libraries will stop supporting it over time, so you'll find it difficult to stay up to date in other places in your stack. If I was running PG 11 in production, I'd be looking to upgrade sooner rather than later. Being on older-but-stable versions is good risk management, being on end-of-life version is not.
Edit: quick check shows we also have PG9 and PG10 in some Live roles too.
My list of unexpected but very welcome changes: - pg_hba.conf and pg_ident.conf can include other files - Logical replication apply can use non-PK btree indexes - Integer literals in non-decimal bases - Underscores in numeric literals - Subqueries in the FROM clause can omit aliases - Addition and subtraction of timestamptz values - pg_upgrade can override new cluster's locale and encoding
https://commitfest.postgresql.org/19/1741/ (index skip scan/loose index scans) would be very welcomed... I think. Not sure how many people run into it in the wild.
It says "target version: 16" but "returned with feedback" and hasn't been bumped in 14 months. :( First opened in 2018.
Postgresql is amazing but I must say the last few updates have been a bit disappointing. Still waiting for automatic incremental updates for materialized views - been worked on for several years but still not released! https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc... https://github.com/sraoss/pg_ivm
Earlier quoted context omitted.
IMO the biggest reason folks use pgbouncer is not for load balancing (which it can do, -ish) but instead for connection pooling. Postgres connections are expensive for the db server (one process per connection not one thread) so if you have say thousands of web application pods you need to use pgbouncer or similar as a proxy to multiplex those thousands of connections down onto a more manageable number (~200). So no,…
Out of curiosity, if the problem of connections being expensive is solvable by PGBouncer-style connection multiplexing, why doesn't Postgres just do that by itself?
My list of unexpected but very welcome changes: - pg_hba.conf and pg_ident.conf can include other files - Logical replication apply can use non-PK btree indexes - Integer literals in non-decimal bases - Underscores in numeric literals - Subqueries in the FROM clause can omit aliases - Addition and subtraction of timestamptz values - pg_upgrade can override new cluster's locale and encoding
This is great. It never made any sense to me that this was required. For people who are unaware, say you want to understand a table a natural way of doing it might be
select *
from the_table
order by some_metric desc
limit 10
select *
from (
select blah blah blah the rest of the query
) a
order by some_metric desc
limit 10