Re: mark/restore failures on unsorted merge joins

2020-11-24 Thread Tom Lane
Andrew Gierth writes: > "Tom" == Tom Lane 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

Re: mark/restore failures on unsorted merge joins

2020-11-24 Thread Andrew Gierth
> "Tom" == Tom Lane 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

Re: mark/restore failures on unsorted merge joins

2020-11-24 Thread Tom Lane
Andrew Gierth writes: > I guess that's close enough; this should suffice then. Looks about right. Not sure if we need to bother with a regression test case; once that's in, it'd be hard to break it. regards, tom lane

Re: mark/restore failures on unsorted merge joins

2020-11-24 Thread Andrew Gierth
> "Tom" == Tom Lane writes: Tom> Oh, sorry, I misread your comment to be that you wanted to add a Tom> field to IndexAmRoutine. You're right, the real issue here is that Tom> ExecSupportsMarkRestore lacks any convenient access to the needed Tom> info, and we need to add a bool to

Re: mark/restore failures on unsorted merge joins

2020-11-24 Thread Tom Lane
Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Uh, why would you not just look to see if the ammarkpos/amrestrpos > Tom> fields are non-null? > We don't (in the back branches) seem to have a pointer to the > IndexAmRoutine handy, only the oid? Oh, sorry, I misread your comment to

Re: mark/restore failures on unsorted merge joins

2020-11-24 Thread Andrew Gierth
> "Tom" == Tom Lane writes: >> The problem is that the planner calls ExecSupportsMarkRestore to >> find out whether a Materialize node is needed, and that function >> looks no further than the Path type of T_Index[Only]Path in order to >> return true, even though in this case it's a GiST

Re: mark/restore failures on unsorted merge joins

2020-11-23 Thread Tom Lane
Andrew Gierth writes: > The problem is that the planner calls ExecSupportsMarkRestore to find > out whether a Materialize node is needed, and that function looks no > further than the Path type of T_Index[Only]Path in order to return true, > even though in this case it's a GiST index which does

mark/restore failures on unsorted merge joins

2020-11-23 Thread Andrew Gierth
>From a report by user "kes" on irc, I constructed this test case: create table marktst (id integer, val numrange, exclude using gist (val with &&)); insert into marktst select i, numrange(i, i+1, '[)') from generate_series(1,1000) i; vacuum marktst; analyze marktst; select * from (select val