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-23 19:54:20 |
Message-ID: | 125707.1606161260@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:
> 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 not support
> mark/restore.
> (Usually this can't be a problem because the merge join would need
> sorted input, thus the index scan would be a btree; but a merge join
> that doesn't actually have any sort keys could take unsorted input from
> any index type.)
Sounds like the right analysis.
> Going forward, this looks like IndexOptInfo needs another am* boolean
> field, but that's probably not appropriate for the back branches; maybe
> as a workaround, ExecSupportsMarkRestore should just check for btree?
Uh, why would you not just look to see if the ammarkpos/amrestrpos fields
are non-null?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Anastasia Lubennikova | 2020-11-23 20:31:20 | Re: DROP relation IF EXISTS Docs and Tests - Bug Fix |
Previous Message | Andrew Gierth | 2020-11-23 19:48:29 | mark/restore failures on unsorted merge joins |