Re: mark/restore failures on unsorted merge joins

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:45:33
Message-ID: 87blfm4hdv.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> I guess that's close enough; this should suffice then.

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.

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-11-24 20:48:15 Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path
Previous Message Robert Haas 2020-11-24 20:44:16 Re: bug in pageinspect's "tuple data" feature