Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sUn1G-005gCU-Ls for pgsql-in-general@arkaria.postgresql.org; Fri, 19 Jul 2024 12:47:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sUn1E-00G124-Oy for pgsql-in-general@arkaria.postgresql.org; Fri, 19 Jul 2024 12:47:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sUn1E-00G11w-HB for pgsql-in-general@lists.postgresql.org; Fri, 19 Jul 2024 12:47:28 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUn1D-000NjE-1N for pgsql-in-general@postgresql.org; Fri, 19 Jul 2024 12:47:28 +0000 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a7523f0870cso217232166b.3 for ; Fri, 19 Jul 2024 05:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721393246; x=1721998046; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=dl2+NjEt/QHrqy1KD2PSm6CasKo6hSEF4E98Ir5+9oM=; b=dVISdnXB6iwOohwmblFWlAaiD7ZaBkzxAMiWyXw9jsgIsZ+lxsKtpNb37kMghjAZI0 lxMXPpoqPxDPAMAr02urFlls2tWfKoihrc5GeKUiglkQuSBpw3830+9Db5vKeWymeFen n7R8EwtrtR1F7tO8Rc1Wm4KlK758eJOCMcvKkNKxsYUjN2jscGVoItXwjehIE7/EXT4E bkOyPlW2ti9XsktgB9auz4ul+KFqCwLJmZp4rxZh5D/vyRfUyHF04+Z7wyPOEH19VXYw XjJ4QU8Kh2K7sprmU1PPsRvawCnhunklIE8X2DQTLSmCuD6rly2LbvXEmjxgxJY2QE+/ V72A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721393246; x=1721998046; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dl2+NjEt/QHrqy1KD2PSm6CasKo6hSEF4E98Ir5+9oM=; b=QLm3/gTAlf22RJkPsNhNespxvTxvkqqhiB1OtFlVNkctoNNAka/+ipvTAzl6+VmEj2 NJ/KugIGes9iztxxTZu7zI0iVplPIEEJ4PRXKhwr9qkOrcX70nj/lGonZXtTjIq8V854 kP162KXyXPcpYZgQSjWr8k63zWtA/kIr6B32EpAEbCLV/SG9f2PBtoEbIOUe8JZe4B0Z H+eHSpT2Z158e0nVjsNyCTmeVzffUbr96jgg5gakle9tCVAlZkTA4F+JRMR83UC0VViK 4ocghpgiVn2jn5rpDGu8vgvJKR5TMdDCw4cLxTyMWGUvdzx945fjgaqpf+EECSBtZRmE pmLA== X-Forwarded-Encrypted: i=1; AJvYcCV3TsxwMS0uNmgsCMY62FecvXxI316Uz2PhmzgfmIfGmzyvPiL6hcfAPaO5jecdDzam0HDe7B+/ExeUt/3jOqDU6/cqArbyfbUesYQE0D/K X-Gm-Message-State: AOJu0YzkIrwXwR5/c2C07zyPECPBZPiSf4A528+Jr6gOE6KB68hXlS1g Aih2uRHdJsYyDqktqKqpIAiHZN4erSQcYKUS95j2HtskMWlGrHyma8nLEr3CRCMN3oKAQMdlX/I dJW1I8wjb3x5ISjNVaNZX1tj92fhtxg== X-Google-Smtp-Source: AGHT+IH8+UaEu6hrhcm4Egu3Ik83CuuYpzaAIUSCpZYF/qyWLhuhFnr8OJYGrzHK54j7FSUKnzvYB/hSbPJ+MOT9YMI= X-Received: by 2002:a17:906:16c3:b0:a77:e48d:bad with SMTP id a640c23a62f3a-a7a011b99b1mr457898066b.32.1721393245665; Fri, 19 Jul 2024 05:47:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Durgamahesh Manne Date: Fri, 19 Jul 2024 18:18:34 +0530 Message-ID: Subject: Fwd: Regarding tables detach concurrently with run_maintenance_proc() To: pgsql-general@lists.postgresql.org, pgsql-in-general@postgresql.org Content-Type: multipart/alternative; boundary="000000000000ed4085061d9918fd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ed4085061d9918fd Content-Type: text/plain; charset="UTF-8" Hi Respected Team with pg_partman By default proc() does not detach tables concurrently. How do we implement tables detach concurrently without blocking other sessions Here queries not using date column to detach tables with run_maintenance_proc() which is not using concurrently based on the retention policy which leads to scan all available child tables hence need to trigger this proc with concurrently option to avoid blocking other child tables beyond rentention policy while running statements on them Do we have any other alternative rather than using pg_partman()? your response is valuable Regards, Durga Mahesh --000000000000ed4085061d9918fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Hi Respected Team

= with pg_partman By default=C2=A0proc() does not detach tables concurrently.= How do we implement tables detach concurrently without blocking other sess= ions=C2=A0
Here queries not using date column to detach tables wi= th run_maintenance_proc() which is not using concurrently=C2=A0 based on th= e retention policy which leads to scan all available child tables hence nee= d to trigger this proc with concurrently option to avoid blocking other chi= ld tables beyond rentention policy while running statements on them

Do we have any other alternative rather than using pg_par= tman()?

your response is valuable=C2=A0
=
Regards,
Durga Mahesh

--000000000000ed4085061d9918fd--