Re: mark/restore failures on unsorted merge joins - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: mark/restore failures on unsorted merge joins
Date
Msg-id 87blfm4hdv.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: mark/restore failures on unsorted merge joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: mark/restore failures on unsorted merge joins  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.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)



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: bug in pageinspect's "tuple data" feature
Next
From: David Rowley
Date:
Subject: Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path