Revert "Track statistics for spilling of changes from ReorderBuffer".
The stats with this commit was available only for WALSenders, however,
users might want to see for backends doing logical decoding via SQL API.
Then, users might want to reset and access these stats across server
restart which w
Revert "Track statistics for spilling of changes from ReorderBuffer".
The stats with this commit was available only for WALSenders, however,
users might want to see for backends doing logical decoding via SQL API.
Then, users might want to reset and access these stats across server
restart which w
HashAgg: before spilling tuples, set unneeded columns to NULL.
This is a replacement for 4cad2534. Instead of projecting all tuples
going into a HashAgg, only remove unnecessary attributes when actually
spilling. This avoids the regression for the in-memory case.
Discussion:
https://postgr.es/m/
Revert "Use CP_SMALL_TLIST for hash aggregate"
This reverts commit 4cad2534da6d17067d98cf04be2dfc1bda8f2cd0 due to a
performance regression. It will be replaced by a new approach in an
upcoming commit.
Reported-by: Andres Freund
Discussion:
https://postgr.es/m/20200614181418.mx4bvljmfkkho...@ala
HashAgg: before spilling tuples, set unneeded columns to NULL.
This is a replacement for 4cad2534. Instead of projecting all tuples
going into a HashAgg, only remove unnecessary attributes when actually
spilling. This avoids the regression for the in-memory case.
Discussion:
https://postgr.es/m/
Revert "Use CP_SMALL_TLIST for hash aggregate"
This reverts commit 4cad2534da6d17067d98cf04be2dfc1bda8f2cd0 due to a
performance regression. It will be replaced by a new approach in an
upcoming commit.
Reported-by: Andres Freund
Discussion:
https://postgr.es/m/20200614181418.mx4bvljmfkkho...@ala
Fix timestamp range handling in regression tests of modules/commit_ts/
Switching the regression tests to use tstzrange() has proved to not be a
good idea for environments where the timestamp precision is low, as
internal range checks exclude the upper bound. So, if the commit
timestamp of a trans
On Sun, Jul 12, 2020 at 09:25:07PM +0900, Michael Paquier wrote:
> longfin has been failing here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2020-07-12%2011%3A49%3A08
>
> The buildfarm logs include no output, but the problem comes from
> -DENFORCE_REGRESSION_TEST_NAME_RES
Fix test failure with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
Replication origins created by regression tests should have names
starting with "regress_", and the test introduced in b1e48bb for commit
timestamps did not do that.
Per buildfarm member longfin.
Discussion: https://postgr.es/m/20
On Sun, Jul 12, 2020 at 11:47:38AM +, Michael Paquier wrote:
> Include replication origins in SQL functions for commit timestamp
>
> While on it, refactor a test of modules/commit_ts/ to use tstzrange() to
> check that a transaction timestamp is within the wanted range, making
> the test a bit
Include replication origins in SQL functions for commit timestamp
This includes two changes:
- Addition of a new function pg_xact_commit_timestamp_origin() able, for
a given transaction ID, to return the commit timestamp and replication
origin of this transaction. An equivalent function existed i
11 matches
Mail list logo
