> > Yes, for some types of sharded applications all that's needed is the
> > ability to produce unions and the relative performance of those doesn't
> > matter.
> >
>
> Exactly. And as far as I understand, the feature OP requested was
> actually just that, nothing more, nothing less.

yes exactly nothing more nothing else

> On the other hand, I can imagine that the feature could actually be
> implemented as a middle tier that does the split & join. But I can also
> imagine that this job can be done more efficiently inside the DB engine,

yes, this what we do now, we shard inside the application and believe me the stats are unbelievable (if you limit your select of course). but i thing this will be a great feature if we can move this middle tiers code inside firebird. as i see, the way sphinx do look like very good :

Create a virtual database maindatabase{
Agent1: host:port:databasename1
Agent2: host:port:databasename2
...
Agentn: host:port:databasenamen
}

and that all, you can use the maindatabase like you query normal database (but you can't update it, you are responsible to update
directly the shard)

> That said, I think OP is underestimating the work implied. It's not
> enough to implement the feature inside the engine. You also need to
> create an interface for it in the client API etc.

yes when i say 1 or 2 days it's what it's take me to create the middle tiers app, it's will be a little more to do it inside the engine to handle all possible scenarios