PostgreSQL

21 February 2026 02:55

Linux 7.0 Shows Significant PostgreSQL Performance Gains On AMD EPYC Review - Phoronix
https://www.phoronix.com/review/linux-70-amd-epyc-turin/2

PostgreSQL

18 February 2026 15:24

So much so that I have deferred the feature for so long

But it can’t wait anymore, I guess. Especially now that there doesn’t seem to be any movement in that area

PostgreSQL

18 February 2026 15:22

Most definitely not free, if it’s coming from Oracle

PostgreSQL

18 February 2026 15:16

Not an Oracle guy, but AFAIK they have this "flashback" feature. No idea if that's a) standard compliant b) free or comes with costs (guess so).

PostgreSQL

18 February 2026 14:46

Just with a strange performance and even stranger modifications!

PostgreSQL

18 February 2026 14:31

I have a feature I’ve managed to defer for almost 2 years now because I was waiting for it to happen

I think WITH SYSTEM TIME AS OF is easier if it comes baked in

That and, using a managed database, I can’t install the periods extension so bummer

PostgreSQL

18 February 2026 13:56

I don't think it's sad.

SQL as a standard is already overbloated with app-level features.

And temporal/bitemporal is mostly app-level (at leas as of now). Nothing special is of urgent need in the engine, just another set of fields and index search.

So, it seems better to wait while there are would be some implementations to look at them, look what they need, look for common features — and then implement something in the server core...

PostgreSQL

18 February 2026 07:44

Does anyone know about the current state of bitemporal features in PostgreSQL (in built, not with extensions)?

Last I remember, work was being done to include that

PostgreSQL

18 February 2026 07:32

I usually don't recommend for less then 2TB.

(Except archive pseudo-partitioning, which often become usable much faster)

PostgreSQL

17 February 2026 19:46

0. Reconsider if you really want this.

1. Create your partitioned table. See https://www.dbi-services.com/blog/postgresql-partitioning-4-hash-partitioning/ for an example of creating a hash partitioned table

2. Copy the data from the old to the partitioned table (think about supporting data changes during the copy or not)

3. Lock both tables with an access exclusive lock

4. Rename the old table to table_old, rename the partitioned table to the original table name.

5. Commit

6. Check of everything works correctly

7. Drop your old table

PostgreSQL

17 February 2026 02:08

this is a request from application team, do you know what is the best method to archive it?

PostgreSQL

16 February 2026 13:18

lose archive_timeout data is like the scenario i said before?
pg_receive_wal means it will backup the WAL that is being written now and not yet being archived?

PostgreSQL

16 February 2026 13:07

There are other backup tools like barman that allow you to have a standby using pg_receive_wal to avoid ARCHIVER lose of data

PostgreSQL

16 February 2026 12:54

so it's possible only if the WAL will be archived right?

PostgreSQL

16 February 2026 12:28

if im taking full backup using pgbackrest then i insert more data and capture the timestamp right before this insert.
is it possible to restore to this point? or only if the WALs been archived by pgbackrest? without issuing pg_switch_wal

PostgreSQL

18 February 2026 18:54

Does anybody have pdf for “PostgreSQL 16 Administration Cookbook”.. Thanks in Advance

PostgreSQL

18 February 2026 15:23

I don’t think it’ll be that bad

Just…the thought of rolling out timeline tracking and auditing is painful

PostgreSQL

18 February 2026 15:21

Probably because it is very rigid algorithmically.

PostgreSQL

18 February 2026 15:13

Why strange performance?😅

PostgreSQL

18 February 2026 14:32

Is that the same as Oracle?🤔
I heard oracle or something of the sort has it too

PostgreSQL

18 February 2026 14:07

DB2 has at least some of the requested features.

The main advantage of implementing what's in the standard would be that ORMs could use the features. Which - come to think of it - sounds terrifying 😅

PostgreSQL

18 February 2026 09:58

According to commitfest, no activity in that field since 2021. Which is kind of sad. On the plus side it's something you can earn some merits with a good patch, I guess 😏

PostgreSQL

18 February 2026 07:39

Don't full vacuum at first.

Generally, it's not necessary.
At the very last there is a pg_repack, but most of the time it doesn't needed either.

Second approach is to use logical replication and switchover for maintenance. Requires a lot of effort, though, and kinda fragile (complex machinery underneath, a lot of sequential operations on replicas...)

PostgreSQL

18 February 2026 00:31

4b) check for any views that refer to the old table and redefine them (ask me how I know... 🤪)

PostgreSQL

17 February 2026 08:48

I need support for postgresql

PostgreSQL

16 February 2026 18:29

And you also config pg_receive_wal like a synchronous standby and you would not lose any info and you also will have some reduction of performance due to wait of confirmation

PostgreSQL

16 February 2026 13:09

I think pg_backrest doesn't support pg_receive_wal

PostgreSQL

16 February 2026 13:05

If you use backup tool based on archiver you would lose archive_timeout data

PostgreSQL

16 February 2026 12:35

Yes, but if you only have pgBackRest as a means to retrieve the WAL then you have to wait for the entire last WAL file to be archived first, either by pg_switch_wal or PG deciding to archive it of it's own initiative because of archive_timeout or the WAL file being full.

PostgreSQL

15 February 2026 17:20

Sometimes it can be ones you do not expect, e.g. we had system table bloat with pg_attribute/index etc. because our temp search results are stored as new unlogged tables in the app and so there was a lot of metadata churn. Can be bad for perf if you let that get away from you.