From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Add support for MERGE SQL command
In-reply-to: <E1nYqfU-001lhQ-BJ@gemulon.postgresql.org>
References: <E1nYqfU-001lhQ-BJ@gemulon.postgresql.org>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Mon, 28 Mar 2022 14:48:29 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <537758.1663625579.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Sep 2022 18:12:59 -0400
Message-ID: <537759.1663625579@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/537759.1663625579%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Add support for MERGE SQL command

komodoensis just failed in a way that demonstrates instability of
the MERGE tests [1].  It looks to me like a background autovacuum
came along and processed one or both of ex_msource and ex_mtarget,
causing their default join plan to change to something else.
Probably an explicit ANALYZE would serve to stabilize that,
but it might end up with a slightly different plan than what
we have now.  It's not clear if that matters?

I also wonder whether we'd need to re-analyze after each of the
explain_merge calls, because those are changing the tables
and hence potentially provoking background stats updates.

It might be better to change these to temp tables.  You'd then
have to filter the temp schema out of the results; but since you
have a filtering function anyway, that doesn't seem too hard.

			regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dkomodoensis&=
dt=3D2022-09-19%2011%3A32%3A56