Re: mark/restore failures on unsorted merge joins

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, kes-kes(at)yandex(dot)ru
Subject: Re: mark/restore failures on unsorted merge joins
Date: 2020-11-24 20:49:33
Message-ID: 309288.1606250973@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> Looks about right. Not sure if we need to bother with a regression
> Tom> test case; once that's in, it'd be hard to break it.

> We could check the EXPLAIN output (since the Materialize node would show
> up), but it's not easy to get stable plans since the choice of which
> path to put on the outside is not fixed. Based on what I found when
> actually testing the code, it probably wouldn't be worth the effort.

If it's not easy to test, I agree it's not worth it.

(Given how long it took anyone to notice this, the difficulty of
making a stable test case is unsurprising, perhaps.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2020-11-24 20:59:20 Re: libpq compression
Previous Message David Rowley 2020-11-24 20:48:15 Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path