On Mon, Jul 20, 2009 at 12:29 PM, Greg Stark wrote:
> On Mon, Jul 20, 2009 at 7:40 PM, Alan Li wrote:
> > Attached is an updated patch that removes the O(n^2) behavior and the
> > awkwardness of optimizing the seqscan path as the plan was about to be
> > created. Now, the optimization is conside
On Mon, Jul 20, 2009 at 7:40 PM, Alan Li wrote:
> Attached is an updated patch that removes the O(n^2) behavior and the
> awkwardness of optimizing the seqscan path as the plan was about to be
> created. Now, the optimization is considered when appendrel is generating
> the paths.
>
> I also chang
On Sat, Jul 18, 2009 at 12:04 PM, Greg Stark wrote:
> On Sat, Jul 18, 2009 at 6:35 PM, Alan Li wrote:
> > Yeah, are you running into the same issue as well? I tried to figure out
> a
> > way around the O(n^2) behavior, but there were no existing direct
> > relationship between the child subpath
On Sat, Jul 18, 2009 at 6:35 PM, Alan Li wrote:
> Yeah, are you running into the same issue as well? I tried to figure out a
> way around the O(n^2) behavior, but there were no existing direct
> relationship between the child subpath and its associated AppendRelInfo. I
> think an AppenRelInfo dyn
On Sat, Jul 18, 2009 at 3:13 AM, Greg Stark wrote:
> This part:
>
> ! /* only try to optimize children rel's */
> ! foreach (lc, root->append_rel_list)
> ! {
> ! AppendRelInfo *a = (AppendRelInfo *) lfirst(lc);
> !
> !
This part:
! /* only try to optimize children rel's */
! foreach (lc, root->append_rel_list)
! {
! AppendRelInfo *a = (AppendRelInfo *) lfirst(lc);
!
! if (a->child_relid == childrel->relid
On Fri, Jul 17, 2009 at 2:45 PM, Greg Stark wrote:
> Neat! I haven't read the patch yet but I have some questions.
>
> Does this handle the case where some partitions have an index and
> others don't? Ie. Does it just apply the regular optimization to each
> partition and then slap on the aggrega
Neat! I haven't read the patch yet but I have some questions.
Does this handle the case where some partitions have an index and
others don't? Ie. Does it just apply the regular optimization to each
partition and then slap on the aggregate node? I think that's actually
a realistic case because peop
Consider the following schema:
create table foo_archive (a int, b timestamp);
create index foo_archive_idx on foo_archive(b);
CREATE TABLE foo_archive_2007_01_01 (CONSTRAINT
foo_archive_2007_01_01_b_check CHECK (((b >= '2007-01-01'::date) AND (b <
'2007-01-02'::date INHERITS (foo_a
