From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Cc: kes-kes@yandex.ru
Subject: Re: mark/restore failures on unsorted merge joins
Date: Tue, 24 Nov 2020 19:41:35 +0000
Message-ID: <87ft4y4lxm.fsf@news-spur.riddles.org.uk> (raw)
In-Reply-To: <293167.1606242810@sss.pgh.pa.us>
References: <87o8jn50be.fsf@news-spur.riddles.org.uk>
<125707.1606161260@sss.pgh.pa.us>
<87k0ua4p4u.fsf@news-spur.riddles.org.uk>
<293167.1606242810@sss.pgh.pa.us>
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> 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 IndexOptInfo to fix that.
Tom> I don't see any compelling reason why you couldn't add the field
Tom> at the end in the back branches; that's what we usually do to
Tom> avoid ABI breaks. Although actually (counts fields...) it looks
Tom> like there's at least one pad byte after amcanparallel, so you
Tom> could add a bool there without any ABI consequence, resulting in a
Tom> reasonably natural field order in all branches.
I guess that's close enough; this should suffice then.
--
Andrew (irc:RhodiumToad)
Attachments:markpos.patch (text/x-patch, 1.7K) downloaddiff --git a/src/backend/executor/execAmi.c b/src/backend/executor/execAmi.cindex e2154ba86a..0c10f1d35c 100644--- a/src/backend/executor/execAmi.c+++ b/src/backend/executor/execAmi.c@@ -417,6 +417,11 @@ ExecSupportsMarkRestore(Path *pathnode)
{
case T_IndexScan:
case T_IndexOnlyScan:
+ /*+ * Not all index types support mark/restore.+ */+ return castNode(IndexPath, pathnode)->indexinfo->amcanmarkpos;+
case T_Material:
case T_Sort:
return true;
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.cindex 52c01eb86b..3e94256d34 100644--- a/src/backend/optimizer/util/plancat.c+++ b/src/backend/optimizer/util/plancat.c@@ -284,6 +284,8 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
info->amhasgettuple = (amroutine->amgettuple != NULL);
info->amhasgetbitmap = amroutine->amgetbitmap != NULL &&
relation->rd_tableam->scan_bitmap_next_block != NULL;
+ info->amcanmarkpos = (amroutine->ammarkpos != NULL &&+ amroutine->amrestrpos != NULL);
info->amcostestimate = amroutine->amcostestimate;
Assert(info->amcostestimate != NULL);
diff --git a/src/include/nodes/pathnodes.h b/src/include/nodes/pathnodes.hindex abe6f570e3..5a10c1855d 100644--- a/src/include/nodes/pathnodes.h+++ b/src/include/nodes/pathnodes.h@@ -864,6 +864,7 @@ struct IndexOptInfo
bool amhasgettuple; /* does AM have amgettuple interface? */
bool amhasgetbitmap; /* does AM have amgetbitmap interface? */
bool amcanparallel; /* does AM support parallel scan? */
+ bool amcanmarkpos; /* does AM support mark/restore? */
/* Rather than include amapi.h here, we declare amcostestimate like this */
void (*amcostestimate) (); /* AM's cost estimator */
};
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: andrew@tao11.riddles.org.uk, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, kes-kes@yandex.ru
Subject: Re: mark/restore failures on unsorted merge joins
In-Reply-To: <87ft4y4lxm.fsf@news-spur.riddles.org.uk>
* 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