Sheeri K. Cabral wrote:
On 9/14/08, *Roland Bouman* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    > How about inserting and getting the result back at the same time?
    > (Postgres does this already)  Or inserting into two tables at once?
    > Or deleting from one table and inserting into another at the same
    > time?  Or deleting while getting back the deleted rows?  (That would
    > be a "queue", but it would be useful for a lot more than that --
    think
    > data archiving -- DELECT FROM foo INTO foo_archive WHERE ....")


    Agree with Stewart. Batched client protocol. Would be nice too because
    it may be easier for the receiving end to shell out the statements to
    multiple nodes and execute the batch in parallel.


Actually, it goes a bit beyond batched client protocol. Specifically in an "archiving" context, I'd like to see some kind of functionality like Unix's &&. "Take this record, insert it into this table, and iff that was successful, delete it." (iff=if and only if)


This is what I've been calling (sometimes) blob-in/blob-out or (sometimes) aggregating protocols. Some that can pass in a hunk of data, mulch it in the server with as many SQL statements as it takes, and sending it back as a hunk. Everything in one round trip.

There isn't a snowball's chance in hell of getting agreement on a one aggregating interface, so defining then as a class to be implemented with plugins makes the most sense.

What I'm currently noodling in Falcon is a general connect mechanism. I'm leaning towards a connect packet contain a chunk of XML that provide authentication information, identifies the aggregating interface, and is extensible for interface-specific crud. I expect the "plain vanilla" SQL interface will be a special case of a particularly dumb aggregating interface.

I think we can all (exception, perhaps, Brian) agree that gating factor in database performance is round trip latency between the client and server. Moving logic to the server reduces the round trips to everyone's benefit. And just as long as we don't have to agree on the "one true aggregating" interface, we can make some real progress.


_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to