> Not necessarily --- the aggregate and group nodes must be there, but
> we don't want to commit to seqscan&sort vs. indexscan sooner than we
> have to. I think what's needed here is some notion of an abstract
> plan tree. The trick is to pick the right level of abstraction.
> Maybe "Aggregate -> Group -> OrderedTupleSource" is the way to think
> about it.
>
> But your end point is valid: we want to be able to make a structure
> like that be an input to a higher-level plan tree. This is also
> necessary for subselect in FROM clause, isn't it?
>
> > Again, who knows enough about the planner to be able to do
> > this kind of stuff?
>
> I could take it on, but I have a lot of other stuff I want to do for
> 7.0. Is this more important than fixing fmgr or improving the
> planner's selectivity estimates? I dunno...
Let me make a comment. Seems like a whole host of problems will be
fixed by this overhaul, but none of the problems is major.
Jan's foreign key support, Vadim's WAL, and Tom Lane's cleanups are of
major importance for 7.0, so it seems we better focus on those, and if
we have time before 7.0, and all people involved have time, we can take
on that work. We will need to have most of us available to discuss and
merge the changes into all the affected areas.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
