From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Add support for MERGE SQL command |
Date: | 2022-09-19 22:12:59 |
Message-ID: | 537759.1663625579@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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=komodoensis&dt=2022-09-19%2011%3A32%3A56
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-09-19 22:15:07 | pgsql: Consistently use named parameters in timezone code. |
Previous Message | Peter Geoghegan | 2022-09-19 22:11:40 | pgsql: Consistently use named parameters in regex code. |