Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pmAIU-0005Kh-Cv for pgsql-sql@arkaria.postgresql.org; Tue, 11 Apr 2023 09:28:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pmAIR-0001cd-9H for pgsql-sql@arkaria.postgresql.org; Tue, 11 Apr 2023 09:28:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pmAIQ-0001cU-Uw for pgsql-sql@lists.postgresql.org; Tue, 11 Apr 2023 09:28:15 +0000 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pmAIO-0001lq-Gr for pgsql-sql@lists.postgresql.org; Tue, 11 Apr 2023 09:28:13 +0000 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-94e102534d6so43601766b.2 for ; Tue, 11 Apr 2023 02:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681205291; x=1683797291; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=B3hzEIxdmpP3F+IX1vk7HVs+PWZQN0ycHYHay1U11N8=; b=NwvEDxSR+y7MMR3zk0K3ltDu4l2BAAY3liiYIMmLQdlNEFKo75DGE3VjkeURI1rmVn ZZJDTbO40cHaKv9rcqtg0YCpNjRfWpR5mfNhg74PoPUqG1bbIdvpKdayhSD5LY6pbvX7 jwBeZztnO6APA4b593W9JshrZ2dVnF3hT2Y8UYYE1StgGb0semxo83tYAcSej6bXNVN9 cBxIxWQapvMcf7osLl+ieU00qFT0u2lJZRUOyq9hoVGxw7yVXgbhUPYj3l/44CZ1zaul j7ZZ7OvH2+2fIGqVqExthLPHqVGzXY1qbCIS2SRgEzDdH9UK0b7H1FZYuZKW35jljOSo 7sag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681205291; x=1683797291; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=B3hzEIxdmpP3F+IX1vk7HVs+PWZQN0ycHYHay1U11N8=; b=gFxhD+NhcdPbZFD4dc45kOURmcwN01vxNp5rgJ9O1GSKn3u/+JgzLZoE37czUYns46 uZ2zHxqcAV3GuG5iazpAzRH/l/MRAoVtfLE9eR7D8kqy2B23RIu4eySgk0Yow7dfqSw1 iufgYBIqlZ84Fg+jiVCIzqYoWekJ/KVKQDMYtFoNuUq4OPgVdxMoV0WVmu6VmtFInGvC q7XktejY20hX0Ik77On48CcGlNsZgHex/b4fv4lqeNjdeX2l5CJLVq95O2ZW5pyc4Pko Yq4BtoQs6uW0ZqUo5bVFADURUbXuKiQfHajr1AOus9oD4LAV+bOSLjSKkaR/PG4g+1iB 7MJg== X-Gm-Message-State: AAQBX9ex0wpSH9iZxCV0/gtqeb1/r+xxsFKtZR/TZKPHS3AE8zN0B4jL 6b6oQf9ts3/rvcb8Y+E2qZRJ7kg8EmK1ePEikVsC6NEb X-Google-Smtp-Source: AKy350YWhcmGXRYsWmqI2MiZloyGd07Y1ZToz7HKxp/wTjHoH2RNK7PLXXiTgWoZA/kvjDpOpp+mXOC8iUg/MVrwTtk= X-Received: by 2002:a50:9f22:0:b0:504:a610:7a3a with SMTP id b31-20020a509f22000000b00504a6107a3amr759063edf.5.1681205291013; Tue, 11 Apr 2023 02:28:11 -0700 (PDT) MIME-Version: 1.0 From: Shaozhong SHI Date: Tue, 11 Apr 2023 10:27:59 +0100 Message-ID: Subject: Looking for an efficient way to replace efficient NOT IN when landling very large data To: pgsql-sql Content-Type: multipart/alternative; boundary="0000000000002a5c7805f90c1cba" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002a5c7805f90c1cba Content-Type: text/plain; charset="UTF-8" Select a.id, a.name, b.id, b.name from a_large_table a, definitive b where ( a.id, b.name) not in (select b.id, b.name from definitive b) is very slow. Is there a faster way to do so? Regards, David --0000000000002a5c7805f90c1cba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable