From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pgsql-hackers@lists.postgresql.org
Cc: kes-kes@yandex.ru
Subject: Re: mark/restore failures on unsorted merge joins
Date: Mon, 23 Nov 2020 14:54:20 -0500
Message-ID: <125707.1606161260@sss.pgh.pa.us> (raw)
In-Reply-To: <87o8jn50be.fsf@news-spur.riddles.org.uk>
References: <87o8jn50be.fsf@news-spur.riddles.org.uk>
Andrew Gierth <andrew@tao11.riddles.org.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, pgsql-hackers@lists.postgresql.org, kes-kes@yandex.ru
Subject: Re: mark/restore failures on unsorted merge joins
In-Reply-To: <125707.1606161260@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox