Refactoring query_planner() callback

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Refactoring query_planner() callback
Date: 2018-06-15 12:59:12
Message-ID: 38a214e3-e594-fba4-3b2d-00c3f887d7dd@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While hacking around the planner, the "callback" mechanism in
query_planner started to feel awkward. It would seem more natural to
split query_planner() into two parts: one function to do all the
pre-processing of the jointree, building equivalence classes etc. And a
second function to generate the Paths.

So where the callers currently do this:

/* set up callback arguments */
qp_extra.foo = ...;
qp_extra.bar = ...;

query_planner(root, qp_callback, &qp_extra);

static void
qp_callback(PlannerInfo *root, void *qp_extra)
{
root->sort_pathkeys = ...;
root->query_pathkeys = ...;
}

This would feel more natural to me:

/* process the jointree, build equivalence classes */
process_jointree(root);

/* set up query_pathkeys */
root->sort_pathkeys = ...;
root->query_pathkeys = ...;

query_planner(root);

Attached is a more full-fledged patch to do that.

The callback was introduced by commit db9f0e1d9a. The commit message
explains the choice to use a callback like this:

> There are several ways in which we could implement that without making
> query_planner itself deal with grouping/sorting features (which are
> supposed to be the province of grouping_planner). I chose to add a
> callback function to query_planner's API; other alternatives would have
> required adding more fields to PlannerInfo, which while not bad in itself
> would create an ABI break for planner-related plugins in the 9.2 release
> series. This still breaks ABI for anything that calls query_planner
> directly, but it seems somewhat unlikely that there are any such plugins.

In v12, we can change the ABI.

- Heikki

Attachment Content-Type Size
0001-Refactor-query_planner-into-two-parts.patch text/x-patch 17.7 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-06-15 13:58:16 Re: why partition pruning doesn't work?
Previous Message Etsuro Fujita 2018-06-15 11:56:20 Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.