Paul McCullagh wrote:
On Dec 22, 2009, at 12:23 AM, Stewart Smith wrote:
On Mon, Dec 21, 2009 at 02:26:43AM -0800, Monty Taylor wrote:
Paul McCullagh wrote:
So in passthruStatement() the engine actually executes the entire
SELECT
statement, and returns the result rows.
This code would only be used if the engine executes the entire SELECT.
If the engine executes only parts of the statement, then the cursor
interface will be used.
I like this. It would make things like FederatedX EXTREMELY easier. (can
haz passthru. k thx bye)
and join to local table... boom.
It's a bit all-or-nothing, and that's my problem with it. Try this
with even a subselect where only the subselect is executable by the
engine.
It is all or nothing, but this done _not_ exclude "partial" solutions
such as condition push-down and sub-select execution.
Is it not better being consulted in optimiser (to make decisions on if
certain transformations should be done or not) and then have the
engine able to change the execution plan to its liking (replacing
parts of the tree with objects that go and do things directly)?
Yes, I think this is required, however, the option for the engine to do
everything may still make sense.
A lot depends on what form the GPB representation of a SELECT will take.
Does it just describe the SELECT as written by the user, or is the
SELECT presented as an execution plan?
It will be whatever you want it to be. ;) It hasn't been designed yet.
-jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
