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.96) (envelope-from ) id 1vuWm4-00BWPU-0A for pgsql-performance@arkaria.postgresql.org; Mon, 23 Feb 2026 14:19:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vuWm2-00DagF-2n for pgsql-performance@arkaria.postgresql.org; Mon, 23 Feb 2026 14:18:58 +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.96) (envelope-from ) id 1vuWm2-00Dag7-1d for pgsql-performance@lists.postgresql.org; Mon, 23 Feb 2026 14:18:58 +0000 Received: from smtp.dieregierung.at ([95.179.190.124]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vuWlz-00000000sQV-2JUS for pgsql-performance@lists.postgresql.org; Mon, 23 Feb 2026 14:18:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codecat.at; s=default; t=1771856334; bh=QQ+kyI0ixxovlMdHkumZ74Qxz+oT8lw7jNKfqKoSN7o=; h=Date:To:From:Subject:From; b=Vxx5e3lFTdBe93XTEUecyK4CpnhBgwuBhn9rDegDGQlDVt3zYmVPKacOs7k4o3s6g zDM0s4IgXWwJLFXOS9NU/E1ORP1iUNFF4yscnMTr5NR1YUziwXDFfdmLSK4RunNuEK yMT30JFYVLQSuoNKekJ3byOUFgv/LUQM5FtFijTo= Message-ID: Date: Mon, 23 Feb 2026 15:18:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: pgsql-performance@lists.postgresql.org From: =?UTF-8?Q?Lea_F=C3=BChrer?= Subject: MERGE INTO... WHEN NOT MATCHED BY SOURCE index usage Organization: CodeCat GmbH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello! I've read through the new MERGE documentation with the new WHEN NOT MATCHED BY SOURCE functionality and tried it out. It seems to me like one very common use-case, and one I have bumped into often, is to update a n:m resolution table, like this for example: CREATE TABLE courses (course_id INTEGER PRIMARY KEY); CREATE TABLE students (student_id INTEGER PRIMARY KEY); CREATE TABLE students_courses (course_id INTEGER REFERENCES courses(course_id), student_id INTEGER REFERENCES students(student_id), PRIMARY KEY(student_id,course_id)); /* Insert example data... */ INSERT INTO students SELECT s FROM generate_series(1,100000) s; INSERT INTO courses SELECT c FROM generate_series(1,50) c; INSERT INTO students_courses (course_id, student_id) SELECT c, s FROM generate_series(1,50) c, generate_series(1,100000) s; /* Student nr 5 is only enrolled in courses 7,8,9 */ MERGE INTO students_courses USING (VALUES (7),(8),(9)) as s(source_course_id) ON students_courses.student_id=5 AND students_courses.course_id = source_course_id WHEN NOT MATCHED BY TARGET THEN INSERT VALUES (source_course_id, 5) WHEN NOT MATCHED BY SOURCE AND student_id=5 THEN DELETE; SELECT * FROM students_courses WHERE student_id=5; The example above works, but looking at the execution plan it does a full seq scan on students_course without any filter for student_id. Do I misunderstand the usage of MERGE WHEN NOT MATCHED BY SOURCE? Is this a non intended use-case? Is there another way of defining a filter for the MERGE command? Updating a many-to-many relationship seems like a very common use-case to me, and the new MERGE seems perfect for this, but in practice the fact it doesn't use an index seems to make it very ineffective performance wise for this.