From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'vignesh C' <vignesh21(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Make default subscription streaming option as Parallel |
Date: | 2024-10-07 06:56:17 |
Message-ID: | TYAPR01MB5692F83F3C7A383FD13A209CF57D2@TYAPR01MB5692.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Vignesh,
> One key point to consider is that the lock on transaction objects will
> be held for a longer duration when using streaming in parallel. This
> occurs because the parallel apply worker initiates the transaction as
> soon as streaming begins, maintaining the lock until the transaction
> is fully completed. As a result, for long-running transactions, this
> extended lock can hinder concurrent access that requires a lock.
So, the current default is the most conservative and can run anywhere; your
proposal is a bit optimistic, right? Since long transactions should be avoided
in any case, and everyone knows it, I agree with your point.
One comment for your patch;
Shouldn't we add a streaming=off case for pg_dump test? You added lines but no one
passes it.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-10-07 07:05:34 | Re: Unlinking Parallel Hash Join inner batch files sooner |
Previous Message | Michael Paquier | 2024-10-07 06:50:26 | Re: Add minimal C example and SQL registration example for custom table access methods. |