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: http://www.postgresql.org/mailpref/pgsql-hackers
