Schedule for 9.5alpha1
There was agreement at the PGCon dev meeting that we should put out a
9.5alpha1 release as soon as possible, to encourage wider testing
(and that it should be called an "alpha", because people aren't convinced
it's up to beta quality yet). After a little back and forth, that release
has been set for next week, ie we'll wrap Monday June 29 for public
announcement Thursday July 2.
If there are any open 9.5 issues you can fix before Monday, please do.
Also, there was agreement that we'd begin the first 9.6 commitfest
on July 1. I anticipate forking off the REL9_5_STABLE branch on
Tuesday to make way for that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
If there are any open 9.5 issues you can fix before Monday, please do.
I have 3 pending bug fixes for UPSERT, including 2 trivial ones. This
does not include my "minor refactoring" patch, which is not a bugfix.
The last of those 3 was posted on 2015-05-30.
I'm rather frustrated that it's so difficult to get maintenance/bugfix
patches committed. Frankly, as a non-committer, I don't see a reason
to bother trying to fix any open 9.5 items by Monday. The probability
of anyone picking them up by then seems very low.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On June 25, 2015 9:35:27 PM GMT+02:00, Peter Geoghegan <pg@heroku.com> wrote:
On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
If there are any open 9.5 issues you can fix before Monday, please
do.
I have 3 pending bug fixes for UPSERT, including 2 trivial ones. This
does not include my "minor refactoring" patch, which is not a bugfix.
The last of those 3 was posted on 2015-05-30.I'm rather frustrated that it's so difficult to get maintenance/bugfix
patches committed. Frankly, as a non-committer, I don't see a reason
to bother trying to fix any open 9.5 items by Monday. The probability
of anyone picking them up by then seems very low.
It'd have been easier if you'd done it the way I asked. This way I have to look much closer...
---
Please excuse brevity and formatting - I am writing this on my mobile phone.--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 25, 2015 at 12:39 PM, Andres Freund <andres@anarazel.de> wrote:
It'd have been easier if you'd done it the way I asked. This way I have to look much closer...
Well, I actually prototyped your approach to that and decided against
it only after having gone to the trouble of doing so. In any case, I
think it's appropriate that you review the wholerow var bugfix patch
carefully. So I'm not talking about that one, as I think you gathered.
I'm not singling you out; clearly you were very busy with other, more
important things the entire time. I'm just giving my perspective.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Friday, June 26, 2015 12:00 AM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] Schedule for 9.5alpha1There was agreement at the PGCon dev meeting that we should put out a
9.5alpha1 release as soon as possible, to encourage wider testing
(and that it should be called an "alpha", because people aren't convinced
it's up to beta quality yet). After a little back and forth, that release
has been set for next week, ie we'll wrap Monday June 29 for public
announcement Thursday July 2.If there are any open 9.5 issues you can fix before Monday, please do.
I have a serious open item reported 1.5 month ago then reminded
several times has not been fixed up yet.
9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp
Patch is less than 100 lines, entirely designed according to Tom's suggestion.
The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted
create_plan_recurse() to static function, thus, extension lost way to
transform Path node to Plan node if it wants to takes underlying child
nodes, like SeqScan, HashJoin and so on.
Tom's suggestion is to add a list of Path nodes on CustomPath structure,
to be transformed by createplan.c, instead of public create_plan_recurse().
It is nearly obvious problem, and bugfix patch already exists.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
Attachments:
custom-join-children.v2.patchapplication/octet-stream; name=custom-join-children.v2.patchDownload
doc/src/sgml/custom-scan.sgml | 12 +++++++++++-
src/backend/commands/explain.c | 22 ++++++++++++++++++++++
src/backend/optimizer/plan/createplan.c | 18 +++++++++++++++++-
src/backend/optimizer/plan/setrefs.c | 8 ++++++++
src/backend/optimizer/plan/subselect.c | 25 +++++++++++++++++++++----
src/include/nodes/execnodes.h | 1 +
src/include/nodes/plannodes.h | 1 +
src/include/nodes/relation.h | 4 +++-
8 files changed, 84 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/custom-scan.sgml b/doc/src/sgml/custom-scan.sgml
index 62a8a33..c7187c7 100644
--- a/doc/src/sgml/custom-scan.sgml
+++ b/doc/src/sgml/custom-scan.sgml
@@ -60,6 +60,7 @@ typedef struct CustomPath
{
Path path;
uint32 flags;
+ List *custom_children;
List *custom_private;
const CustomPathMethods *methods;
} CustomPath;
@@ -73,6 +74,10 @@ typedef struct CustomPath
<literal>CUSTOMPATH_SUPPORT_BACKWARD_SCAN</> if the custom path can support
a backward scan and <literal>CUSTOMPATH_SUPPORT_MARK_RESTORE</> if it
can support mark and restore. Both capabilities are optional.
+ An optional <structfield>custom_children</> is a list of underlying
+ <structname>Path</> nodes that can be executed as input data stream of
+ this custom-path node. If valid list is given, it shall be transformed
+ to the relevant <structname>Plan</> nodes by planner.
<structfield>custom_private</> can be used to store the custom path's
private data. Private data should be stored in a form that can be handled
by <literal>nodeToString</>, so that debugging routines that attempt to
@@ -112,7 +117,8 @@ Plan *(*PlanCustomPath) (PlannerInfo *root,
RelOptInfo *rel,
CustomPath *best_path,
List *tlist,
- List *clauses);
+ List *clauses,
+ List *custom_children);
</programlisting>
Convert a custom path to a finished plan. The return value will generally
be a <literal>CustomScan</> object, which the callback must allocate and
@@ -145,6 +151,7 @@ typedef struct CustomScan
{
Scan scan;
uint32 flags;
+ List *custom_children;
List *custom_exprs;
List *custom_private;
List *custom_scan_tlist;
@@ -159,6 +166,9 @@ typedef struct CustomScan
estimated costs, target lists, qualifications, and so on.
<structfield>flags</> is a bitmask with the same meaning as in
<structname>CustomPath</>.
+ <structfield>custom_children</> can be used to store child
+ <structname>Plan</> nodes, if custom-scan provider takes multiple
+ (more than two) underlying query execution plans.
<structfield>custom_exprs</> should be used to
store expression trees that will need to be fixed up by
<filename>setrefs.c</> and <filename>subselect.c</>, while
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index a82c6ff..059059b 100644
--- a/src/backend/commands/explain.c
+++ b/src/backend/commands/explain.c
@@ -115,6 +115,8 @@ static void ExplainMemberNodes(List *plans, PlanState **planstates,
List *ancestors, ExplainState *es);
static void ExplainSubPlans(List *plans, List *ancestors,
const char *relationship, ExplainState *es);
+static void ExplainCustomChildren(CustomScanState *css,
+ List *ancestors, ExplainState *es);
static void ExplainProperty(const char *qlabel, const char *value,
bool numeric, ExplainState *es);
static void ExplainOpenGroup(const char *objtype, const char *labelname,
@@ -1624,6 +1626,8 @@ ExplainNode(PlanState *planstate, List *ancestors,
IsA(plan, BitmapAnd) ||
IsA(plan, BitmapOr) ||
IsA(plan, SubqueryScan) ||
+ (IsA(planstate, CustomScanState) &&
+ ((CustomScanState *) planstate)->custom_children != NIL) ||
planstate->subPlan;
if (haschildren)
{
@@ -1678,6 +1682,10 @@ ExplainNode(PlanState *planstate, List *ancestors,
ExplainNode(((SubqueryScanState *) planstate)->subplan, ancestors,
"Subquery", NULL, es);
break;
+ case T_CustomScan:
+ ExplainCustomChildren((CustomScanState *) planstate,
+ ancestors, es);
+ break;
default:
break;
}
@@ -2648,6 +2656,20 @@ ExplainSubPlans(List *plans, List *ancestors,
}
/*
+ * Explain underlying child nodes of CustomScanState, if any
+ */
+static void
+ExplainCustomChildren(CustomScanState *css, List *ancestors, ExplainState *es)
+{
+ ListCell *cell;
+ const char *label =
+ (list_length(css->custom_children) > 1 ? "children" : "child");
+
+ foreach (cell, css->custom_children)
+ ExplainNode((PlanState *) lfirst(cell), ancestors, label, NULL, es);
+}
+
+/*
* Explain a property, such as sort keys or targets, that takes the form of
* a list of unlabeled items. "data" is a list of C strings.
*/
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index a3482de..b935e85 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -2157,6 +2157,21 @@ create_customscan_plan(PlannerInfo *root, CustomPath *best_path,
{
CustomScan *cplan;
RelOptInfo *rel = best_path->path.parent;
+ List *custom_children = NIL;
+ ListCell *lc;
+
+ /*
+ * If CustomPath takes underlying child nodes, we recursively transform
+ * these Path nodes to Plan node.
+ * Custom-scan provider will attach these plans on lefttree, righttree
+ * or custom_children list of CustomScan node.
+ */
+ foreach (lc, best_path->custom_children)
+ {
+ Plan *child = create_plan_recurse(root, (Path *) lfirst(lc));
+
+ custom_children = lappend(custom_children, child);
+ }
/*
* Sort clauses into the best execution order, although custom-scan
@@ -2172,7 +2187,8 @@ create_customscan_plan(PlannerInfo *root, CustomPath *best_path,
rel,
best_path,
tlist,
- scan_clauses);
+ scan_clauses,
+ custom_children);
Assert(IsA(cplan, CustomScan));
/*
diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c
index a7f65dd..71efa85 100644
--- a/src/backend/optimizer/plan/setrefs.c
+++ b/src/backend/optimizer/plan/setrefs.c
@@ -1151,6 +1151,8 @@ set_customscan_references(PlannerInfo *root,
CustomScan *cscan,
int rtoffset)
{
+ ListCell *lc;
+
/* Adjust scanrelid if it's valid */
if (cscan->scan.scanrelid > 0)
cscan->scan.scanrelid += rtoffset;
@@ -1194,6 +1196,12 @@ set_customscan_references(PlannerInfo *root,
fix_scan_list(root, cscan->custom_exprs, rtoffset);
}
+ /* Adjust child plan-nodes recursively, if needed */
+ foreach (lc, cscan->custom_children)
+ {
+ lfirst(lc) = set_plan_refs(root, (Plan *) lfirst(lc), rtoffset);
+ }
+
/* Adjust custom_relids if needed */
if (rtoffset > 0)
{
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c
index f80abb4..6c05663 100644
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -2373,10 +2373,27 @@ finalize_plan(PlannerInfo *root, Plan *plan, Bitmapset *valid_params,
break;
case T_CustomScan:
- finalize_primnode((Node *) ((CustomScan *) plan)->custom_exprs,
- &context);
- /* We assume custom_scan_tlist cannot contain Params */
- context.paramids = bms_add_members(context.paramids, scan_params);
+ {
+ CustomScan *cscan = (CustomScan *) plan;
+ ListCell *lc;
+
+ finalize_primnode((Node *) cscan->custom_exprs,
+ &context);
+ /* We assume custom_scan_tlist cannot contain Params */
+ context.paramids =
+ bms_add_members(context.paramids, scan_params);
+
+ /* child nodes if any */
+ foreach (lc, cscan->custom_children)
+ {
+ context.paramids =
+ bms_add_members(context.paramids,
+ finalize_plan(root,
+ (Plan *) lfirst(lc),
+ valid_params,
+ scan_params));
+ }
+ }
break;
case T_ModifyTable:
diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index db5bd7f..ffdbbfa 100644
--- a/src/include/nodes/execnodes.h
+++ b/src/include/nodes/execnodes.h
@@ -1616,6 +1616,7 @@ typedef struct CustomScanState
{
ScanState ss;
uint32 flags; /* mask of CUSTOMPATH_* flags, see relation.h */
+ List *custom_children;/* list of child PlanState nodes, if any */
const CustomExecMethods *methods;
} CustomScanState;
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index d967219..e936b1b 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes/plannodes.h
@@ -550,6 +550,7 @@ typedef struct CustomScan
{
Scan scan;
uint32 flags; /* mask of CUSTOMPATH_* flags, see relation.h */
+ List *custom_children;/* list of Plan nodes, if any */
List *custom_exprs; /* expressions that custom code may evaluate */
List *custom_private; /* private data for custom code */
List *custom_scan_tlist; /* optional tlist describing scan
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index 279051e..1d3b015 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -927,7 +927,8 @@ typedef struct CustomPathMethods
RelOptInfo *rel,
struct CustomPath *best_path,
List *tlist,
- List *clauses);
+ List *clauses,
+ List *custom_children);
/* Optional: print additional fields besides "private" */
void (*TextOutCustomPath) (StringInfo str,
const struct CustomPath *node);
@@ -937,6 +938,7 @@ typedef struct CustomPath
{
Path path;
uint32 flags; /* mask of CUSTOMPATH_* flags, see above */
+ List *custom_children;/* list of child Path nodes, if any */
List *custom_private;
const CustomPathMethods *methods;
} CustomPath;
On Thu, Jun 25, 2015 at 3:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
It is nearly obvious problem, and bugfix patch already exists.
My current strategy is to post these items on the "PostgreSQL 9.5 Open
Items" page, even when the issue is totally trivial -- maybe that
makes a small difference, even if it sometimes feels inappropriate for
small items.
There are some other items with clear or clear-ish fixes beyond the
ones that I mentioned. For one further example not involving UPSERT,
ISTM based on pgCon discussion that "Arguable RLS security bug,
EvalPlanQual() paranoia" can be fixed with a well written doc patch,
once we figure out exactly how to explain the issue, which should be
straightforward. For another, the rest of the jsonb stuff is now
almost open-and-shut (again, this conclusion is based on discussion
during pgCon, in this instance with Andrew). That fix involves an
actual small adjustment to semantics. This is just the stuff I'm
involved in. I think that the experience of myself and Kaigai-san with
bug fixes are representative.
Some committers request that I post simple bugfixes to the next
commitfest. That might help with making sure that they eventually get
some attention, which makes some sense at a different time in the
cycle, but it does not help at all with making sure that they get
timely attention when we're up against a deadline for putting out a
release (even if it is an alpha). Besides, even when a release is not
upcoming, my strong personal preference is to fix bugs ASAP.
I'm tired of having to chase down known bugs when a patch has been
around for a long time, and an actual fix is blocking on committer
availability -- sometimes I feel the need to privately twist someone's
arm just to get something done that should be straightforward. If this
is the way things are supposed to work, we should document known bugs
in the alpha release notes.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 26, 2015 at 8:03 AM, Peter Geoghegan <pg@heroku.com> wrote:
On Thu, Jun 25, 2015 at 3:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
It is nearly obvious problem, and bugfix patch already exists.
My current strategy is to post these items on the "PostgreSQL 9.5 Open
Items" page, even when the issue is totally trivial -- maybe that
makes a small difference, even if it sometimes feels inappropriate for
small items.
This is the right approach to me, this page being dedicated to that.
And I am doing the same when I spot something.
I'm tired of having to chase down known bugs when a patch has been
around for a long time, and an actual fix is blocking on committer
availability -- sometimes I feel the need to privately twist someone's
arm just to get something done that should be straightforward.
Patience is the key here IMO, committer time being precious. And I
guess that the requirement for the .0 release will be to clear all
those items btw, so they will be fixed at some point.
If this is the way things are supposed to work, we should document known bugs
in the alpha release notes.
Perhaps. Being able to track them in the code tree does not sound like
a bad thing to me.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
I'm tired of having to chase down known bugs when a patch has been
around for a long time, and an actual fix is blocking on committer
availability -- sometimes I feel the need to privately twist someone's
arm just to get something done that should be straightforward.Patience is the key here IMO, committer time being precious. And I
guess that the requirement for the .0 release will be to clear all
those items btw, so they will be fixed at some point.
Some more transparency in both directions, and the ability to triage
bugs would be nice. Sometimes things aren't that complicated, but are
still important (while other times, things can be complicated and
unimportant). I have no good way of making a representation about
which category any given bug fix falls under.
Also, while the commitfest app makes it pretty likely that someone
will get around to considering a bug fix eventually, the time that
that takes is completely unbounded.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/25/2015 05:09 PM, Peter Geoghegan wrote:
On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:I'm tired of having to chase down known bugs when a patch has been
around for a long time, and an actual fix is blocking on committer
availability -- sometimes I feel the need to privately twist someone's
arm just to get something done that should be straightforward.Patience is the key here IMO, committer time being precious. And I
guess that the requirement for the .0 release will be to clear all
those items btw, so they will be fixed at some point.Some more transparency in both directions, and the ability to triage
bugs would be nice. Sometimes things aren't that complicated, but are
still important (while other times, things can be complicated and
unimportant). I have no good way of making a representation about
which category any given bug fix falls under.Also, while the commitfest app makes it pretty likely that someone
will get around to considering a bug fix eventually, the time that
that takes is completely unbounded.
Perhaps Heroku could sponsor a committer or two for triage. I know there
are a couple that are not currently bound by other Pg companies.
Sincerely,
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
I have a serious open item reported 1.5 month ago then reminded
several times has not been fixed up yet.9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp
Patch is less than 100 lines, entirely designed according to Tom's suggestion.
The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted
create_plan_recurse() to static function, thus, extension lost way to
transform Path node to Plan node if it wants to takes underlying child
nodes, like SeqScan, HashJoin and so on.Tom's suggestion is to add a list of Path nodes on CustomPath structure,
to be transformed by createplan.c, instead of public create_plan_recurse().It is nearly obvious problem, and bugfix patch already exists.
Yes, I am quite unhappy with this situation. Tom promised me at PGCon
that he would look at this soon, but there is no sign that he has, and
he said the same thing weeks ago. I think it can't be right to let
this sit for another month or three. Even if the API you've
implemented is worse than something Tom can design, it is certainly
better than the status quo. I would rather have a working but
imperfect API and have to break compatibility later in beta than have
a non-working API.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
I have a serious open item reported 1.5 month ago then reminded
several times has not been fixed up yet.9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp
Patch is less than 100 lines, entirely designed according to Tom's suggestion.
The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted
create_plan_recurse() to static function, thus, extension lost way to
transform Path node to Plan node if it wants to takes underlying child
nodes, like SeqScan, HashJoin and so on.Tom's suggestion is to add a list of Path nodes on CustomPath structure,
to be transformed by createplan.c, instead of public create_plan_recurse().It is nearly obvious problem, and bugfix patch already exists.
Yes, I am quite unhappy with this situation. Tom promised me at PGCon
that he would look at this soon, but there is no sign that he has, and
he said the same thing weeks ago. I think it can't be right to let
this sit for another month or three. Even if the API you've
implemented is worse than something Tom can design, it is certainly
better than the status quo. I would rather have a working but
imperfect API and have to break compatibility later in beta than have
a non-working API.
...given which, I have committed this. I did not like the use of
custom_children as a generic monicker, so I changed it to
custom_paths, custom_plans, or custom_ps, as appropriate in each case.
I did a bit of cosmetic cleanup as well.
This does seem much nicer than giving custom plans direct access to
create_plan_recurse(). The fact that you found various other places
of using those lists demonstrates that nicely.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
I have a serious open item reported 1.5 month ago then reminded
several times has not been fixed up yet.9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp
Patch is less than 100 lines, entirely designed according to Tom's suggestion.
The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted
create_plan_recurse() to static function, thus, extension lost way to
transform Path node to Plan node if it wants to takes underlying child
nodes, like SeqScan, HashJoin and so on.Tom's suggestion is to add a list of Path nodes on CustomPath structure,
to be transformed by createplan.c, instead of public create_plan_recurse().It is nearly obvious problem, and bugfix patch already exists.
Yes, I am quite unhappy with this situation. Tom promised me at PGCon
that he would look at this soon, but there is no sign that he has, and
he said the same thing weeks ago. I think it can't be right to let
this sit for another month or three. Even if the API you've
implemented is worse than something Tom can design, it is certainly
better than the status quo. I would rather have a working but
imperfect API and have to break compatibility later in beta than have
a non-working API....given which, I have committed this. I did not like the use of
custom_children as a generic monicker, so I changed it to
custom_paths, custom_plans, or custom_ps, as appropriate in each case.
I did a bit of cosmetic cleanup as well.This does seem much nicer than giving custom plans direct access to
create_plan_recurse(). The fact that you found various other places
of using those lists demonstrates that nicely.
Thanks for your help!
One advantage of the approach, I think, is custom_paths list allows to
implement N-way (N > 2) join more naturally than just direct accesses
to create_plan_recurse().
The example below shows contents of t1, t2 and t3 are enough small to
load GPU RAM, so the custom "GpuJoin" can run these 4 tables join within
a single step.
postgres=# explain select * from t0 natural join t1 natural join t2 natural join t3;
QUERY PLAN
------------------------------------------------------------------------------------------------
Custom Scan (GpuJoin) (cost=6501.77..249476.48 rows=9899296 width=176)
Bulkload: On (density: 100.00%)
Depth 1: Logic: GpuHashJoin, HashKeys: (cid), JoinQual: (cid = cid), nrows_ratio: 0.98995197
Depth 2: Logic: GpuHashJoin, HashKeys: (aid), JoinQual: (aid = aid), nrows_ratio: 1.00000000
Depth 3: Logic: GpuHashJoin, HashKeys: (bid), JoinQual: (bid = bid), nrows_ratio: 1.00000000
-> Custom Scan (BulkScan) on t0 (cost=0.00..242855.74 rows=9999774 width=77)
-> Seq Scan on t3 (cost=0.00..734.00 rows=40000 width=37)
-> Seq Scan on t1 (cost=0.00..734.00 rows=40000 width=37)
-> Seq Scan on t2 (cost=0.00..734.00 rows=40000 width=37)
(9 rows)
Best regards,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Resolved by subject fallback