Re: Backend-internal SPI operations

Jan Wieck <janwieck(at)yahoo(dot)com> writes:
> So the hard part of the NEW rewriter will be to detect which
> qualifications can be moved/duplicated down into which
> subselects (tuple sources) to restrict scans.

Actually, what I was envisioning was pulling the subselect's guts *up*
into the main query (collapsing out the sub-Query node) if the sub-Query
is simple enough --- that is, no grouping/sorting/aggregates/etc. The
nice thing about that is we can start with a very simple method that
only deals with easy cases. The hard cases will still *work*.
I consider that an improvement over the current situation, where even
simple cases are nightmarishly difficult to implement (as you well know)
and the hard cases don't work. Worst case is that some
intermediate-complexity examples might lose performance for a while
until we build up a smart subquery-merging algorithm, but that seems
a price worth paying.

> Then again, let's get 7.1 out as is

Has the release schedule moved up without my knowing about it?
I don't feel any urgent need to freeze development now...

> and do the full querytree
> redesign for 7.2. It looks easy, but I fear it's more or less
> like an iceberg.

The original reason for this effort was to do a trial balloon that would
give us more knowledge about how to do it right for 7.2. The more I get
into it, the more I realize what a good idea that was. I'm not sure how
much of what I'm doing now will be completely discarded in the 7.2
cycle, but I do know that I understand the issues a lot better than
I did a week ago...

regards, tom lane