On Tue, 2008-07-08 at 17:51 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The notes say "Heikki doesn't think this is a long term solution", but
> > in the following discussion it was the *only* way of doing this that
> > will work with non-PostgreSQL databases. So it seems like the way we
> > would want to go, yes?
>
> How did you come to the conclusion that this is the only way that will
> work with non-PostgreSQL databases?
SQL, in text form, is the interface to other databases. You can't pass
half a plan tree to Oracle, especially not a PostgreSQL plan tree. It
has to be text if you wish to send a query to another RDBMS, or another
version of PostgreSQL.
> We should start moving towards a full SQL:MED solution that will
> ultimately support pushing down joins, aggregates etc. to the remote
> database. Including support for transaction control, using 2PC, and
> cost estimation and intelligent planning.
>
> This should be done in an extensible way, so that people can write
> their own plugins to connect to different RDBMSs, as well as simple
> data sources like flat files. The plugin needs to be able to control
> which parts of a plan tree can be pushed down to the remote source,
> estimate the cost of remote execution, and map remote data types to
> local ones. And it then needs to be able to construct and execute the
> remote parts of a plan.
So if I understand you, you want to pass the partial plan tree and then
have a plugin construct the SQL text. Sounds like a great approach.
Maybe you thought I meant internal interfaces should be in text? No,
that would be bizarre. I meant we should not attempt to pass partial
plan trees outside of the database, since that would limit the feature
to only working with the same version of PostgreSQL database. I support
your wish to have something that can work with other types of database.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
