On Thu, Jun 22, 2023 at 02:58:14PM +0900, Yugo NAGATA wrote: > On Mon, 19 Jun 2023 16:49:05 -0700 > "Tristan Partin" <tris...@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
signature.asc
Description: PGP signature
