On Tue, May 4, 2021 at 4:05 AM Hans Buschmann wrote:
> The main difference is the time shown for the Gather Merge step (65 ms vs. 7
> ms)
No Windows here, but could it be super slow at launching workers? How
does a trivial parallel query compare, something like?
SET force_parallel_mode = on;
E
When developing a solution for a new customer request I created a new query
over the production data.
Despite the relatively low row counts of the involved tables (all < 100k) I
noticed quite a long execution time of about 85 ms to 100 ms.
The explain anaylze plan showed a parallel execution p
On 4/30/21 3:32 PM, Bruce Momjian wrote:
On Sat, Mar 13, 2021 at 08:43:54AM -0500, Jan Wieck wrote:
On 3/12/21 8:30 PM, Michael Paquier wrote:
> Hi Jan,
>
> On Fri, Mar 12, 2021 at 06:13:33PM -0500, Jan Wieck wrote:
> > One of the things in my way is that when using pg_resetwal to put the
> >
Oh, I forgot to tell I was able to recover the secondary by replacing the
000100AA00A0 from the archives into pg_wal. Then the secondary were
able to finish recovery, start streaming replication and fetch subsequent wals.
I wondered why there was a CHECKPOINT_SHUTDOWN record. I dig
Am 03.05.2021 um 10:41 schrieb Laurenz Albe:
On Sat, 2021-05-01 at 12:59 +0200, Wolfgang Rißler wrote:
Am 30.04.2021 um 16:16 schrieb Tom Lane:
I would recommend trying to use a reasonably late-vintage libpq; we do
fix bugs in it on a regular basis.
The common stumbling block for cross-version
On 03/05/2021 10:43, Laurenz Albe wrote:
On Sun, 2021-05-02 at 22:43 +0200, Adrien Nayrat wrote:
LOG: started streaming WAL from primary at AA/A100 on timeline 1
FATAL: could not receive data from WAL stream : ERROR: requested starting
point AA/A100 is ahead of the WAL flush position
On Sun, 2021-05-02 at 22:43 +0200, Adrien Nayrat wrote:
> LOG: started streaming WAL from primary at AA/A100 on timeline 1
> FATAL: could not receive data from WAL stream : ERROR: requested starting
> point AA/A100 is ahead of the WAL flush position of this server
> AA/A0FFFBE8
You ar
On Sat, 2021-05-01 at 12:59 +0200, Wolfgang Rißler wrote:
> Am 30.04.2021 um 16:16 schrieb Tom Lane:
> > I would recommend trying to use a reasonably late-vintage libpq; we do
> > fix bugs in it on a regular basis.
> > The common stumbling block for cross-version situations is that the
> > client m
Am 01.05.2021 um 18:26 schrieb Adrian Klaver:
On 5/1/21 3:59 AM, Wolfgang Rißler wrote:
This is my problem, I completely dont know, how to start compiling my
own actual 32bit libpq on windows (and I would like to do it with VS
2019).
For libpqxx there have been some hints how to do so in the p
