On Thu, Jun 22, 2023 at 02:58:14PM +0900, Yugo NAGATA wrote:
> On Mon, 19 Jun 2023 16:49:05 -0700
> "Tristan Partin" <tristan@neon.tech> wrote:
>> On Mon Jun 19, 2023 at 6:39 AM PDT, Yugo NAGATA wrote:
>>> [1] https://www.postgresql.org/message-id/flat/CSTU5P82ONZ1.19XFUGHMXHBRY%40c3po
>>
>> The other patch does not replace this one. They are entirely separate.
>
> After applying the other patch, CancelRequested would be checked enough frequently
> even during initialization of pgbench_branches and pgbench_tellers, and it will
> allow the initialization step to be cancelled immediately even if the scale factor
> is high. So, is it unnecessary to modify setup_cancel_handler anyway?
>
> I think it would be still nice to introduce a new exit code for query cancel separately.
I have the same impression as Nagata-san while going again through
the proposal of this thread. COPY is more responsive to
interruptions, and is always going to have a much better performance
than individual or multi-value INSERTs for the bulk-loading of data,
so we could just move on with what's proposed on the other thread and
solve the problem of this thread on top of improving the loading
performance.
What are the benefits we gain with the proposal of this thread once we
switch to COPY as method for the client-side data generation? If
the argument is to be able switch to a different error code on
cancellations for pgbench, that sounds a bit thin to me versus the
argument of keeping the cancellation callback path as simple as
possible.
--
Michael