Re: Constraint Exclusion (Partitioning) - Initial Review - Mailing list pgsql-patches

From Simon Riggs
Subject Re: Constraint Exclusion (Partitioning) - Initial Review
Date
Msg-id 1121098578.3970.88.camel@localhost.localdomain
Whole thread Raw
In response to Re: Constraint Exclusion (Partitioning) - Initial Review requested  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
On Sat, 2005-07-02 at 15:56 -0400, Bruce Momjian wrote:
> > Main questions:
> > 1. How should we handle the case where *all* inherited relations are
> > excluded? (This is not currently covered in the code).
>
> I assume this means we don't return any rows.  Why it is an issue?

Not so much an issue as tidy up for a corner case within the code.

I have 3 ways of handling this case:

1. Set the query to scan the first parent relation only (even though we
know we don't have to).

2. Add a flag to RelOptInfo that can be set when this situation occurs,
which would then be used to add a Result(false) top level node at the
end of query_planner in planmain.c

3. Add function return values for a flag to make_one_rel(), just as in
pull_constant_clauses() that would be handled as a a Result(false) top
level node at the end of query_planner in planmain.c. This would require
changes to call parameters of set_base_rel_pathlists() and
set_inherited_rel_pathlist() in allpaths.c

At the moment, this case is not handled in my patch.

(3) is probably structurally the most similar to other existing calls.

I'm not that fussed either way, so will settle towards (3) unless
somebody screams....

Best Regards, Simon Riggs


pgsql-patches by date:

Previous
From: Atsushi Ogawa
Date:
Subject: Re: regexp_replace
Next
From: Peter Eisentraut
Date:
Subject: Re: thousands comma numeric formatting in psql