On Thu, May 8, 2014 at 10:16 PM, Stephen Frost <sfr...@snowman.net> wrote:
> * Robert Haas (robertmh...@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 you all the way to
where you want to be or not.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to