On Thu, May 8, 2014 at 10:16 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> Well, I consider that somewhat good news, because I think it would be
>> rather nice if we could get by with solving one problem at a time, and
>> if the executor part is close to being well-solved, excellent.
>
> Sadly, I'm afraid the news really isn't all that good in the end..
>
>> My ignorance is probably showing here, but I guess I don't understand
>> why it's so hard to deal with the planner side of things. My
>> perhaps-naive impression is that a Seq Scan node, or even an Index
>> Scan node, is not all that complicated. If we just want to inject
>> some more things that behave a lot like those into various baserels, I
>> guess I don't understand why that's especially hard.
>
> That's not what is being asked for here though...
I am not sure what your point is here. Here's mine: if we can strip
this down to the executor support plus the most minimal planner
support possible, we might be able to get *something* committed. Then
we can extend it in subsequent commits.
You seem to be saying there's no value in getting anything committed
unless it handles the scan-substituting-for-join case. I don't agree.Incremental commits are good, whether they get
youall the way to
where you want to be or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company