Konstantin Knizhnik

Проблема на в пасмане и не в extract, а в with time zone. Если вы попробуете создать функциональный индекс, то получите такую же ошибку: create table tt(t timestamp with time...

Actually I do not understand why we are so optimistic here. This wal redo optimization provides ~1o% percent improvement. Launching more than one wal-redo postgres is IMHO no so good...

> This forces image creation for a key-range, even if there have been no updates after the last image. That's not good. I have to agree with you. It was...

Results at my laptop (default settings but `wal_log_hints=off`): pgbench -i -s 100: ``` main: done in 52.28 s (drop tables 0.00 s, create tables 0.05 s, client-side generate 16.41 s,...

More performance comparison results: pgbench -s -s 1000: ``` main: done in 569.47 s (drop tables 0.00 s, create tables 0.02 s, client-side generate 184.40 s, vacuum 192.11 s, primary...

> The safe way to do this is to have a global view of the whole WAL stream, and only coalesce records between commit records. But I still do not...

> I guess, but makes it pretty limited. I have only one scenario in my mind where such optimization can be useful: bulk loading. Index build is stored in WAL...

I am sorry that my explanation are so large and may be unclear. I try to enumerate them briefly: 1. Presence of other transaction is not important because we can...

> I was thinking of a replica that follows the primary. Frankly speaking I still do not sure how such replica can be maintained and do we need such replica...

I understand your example with branching. But what s the role of "0x03: COMMIT (transaction B)" in this story? Looks like the some problem persists even if transaction B is...