On 2017/07/26 6:07, Robert Haas wrote:
On Thu, Jul 13, 2017 at 1:09 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote:
Attached is a WIP patch (make_resultrels_ordered.patch) that generates
the result rels in canonical order. This patch is kept separate from
the update-partition-key patch, and can be applied on master branch.
Thank you for working on this, Amit!
Hmm, I like the approach you've taken here in general,
+1 for the approach.
Is there any real benefit in this "walker" interface? It looks to me
like it might be simpler to just change things around so that it
returns a list of OIDs, like find_all_inheritors, but generated
differently. Then if you want bound-ordering rather than
OID-ordering, you just do this:
list_free(inhOids);
inhOids = get_partition_oids_in_bound_order(rel);
That'd remove the need for some if/then logic as you've currently got
in get_next_child().
Yeah, that would make the code much simple, so +1 for Robert's idea.
I think we should always expand in bound order rather than only when
it's a result relation. I think for partition-wise join, we're going
to want to do it this way for all relations in the query, or at least
for all relations in the query that might possibly be able to
participate in a partition-wise join. If there are multiple cases
that are going to need this ordering, it's hard for me to accept the
idea that it's worth the complexity of trying to keep track of when we
expanded things in one order vs. another. There are other
applications of having things in bound order too, like MergeAppend ->
Append strength-reduction (which might not be legal anyway if there
are list partitions with multiple, non-contiguous list bounds or if
any NULL partition doesn't end up in the right place in the order, but
there will be lots of cases where it can work).
+1 for that as well. Another benefit from that would be EXPLAIN; we
could display partitions for a partitioned table in the same order for
Append and ModifyTable (ie, SELECT/UPDATE/DELETE), which I think would
make the EXPLAIN result much readable.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
