> > > > Why not create a Stored Procedure for this :-)
> > > >
> > >
> > > selecting * for 280000 records in an SP is notmuch better than
> > doing it at
> > > the client. In an SP, the server will still cache them out to disk

again

> >
> > Well, you do avoid the network traffic and the client side
> > caching problem.
> >
> > > before it starts to walk thru them.
> > > It's miles better to keep them in the fdb file and memory only
> > - not back
> > > out onto disk again.
> >
> > They don't _have_ to go to disk if Firebird doesn't want to. It depends
> > on the current cache fill, the amount of memory available etc ...
> >
> > Either way, if Firebird didn't want to handle several thousands
> > of records,
> > it shouldn't have become a database engine ;-)
>
> it's all about bottle necks though isn't it?
> if you can select only the records you need and that number of records
> avoids secondary caching on disk and maybe it even keeps up with the band
> width available to it to offload them, then bottlenecks are kept to a
> minimum and other users are kept happy because overall performance is
> maximised.
> On the other hand if you want your database engine to remain bogged down

in

> I/O instead of getting it to do what it's best at doing (unions hey)...

then

> go for it.

Sure, you should keep performance maxed, but if you actually need these
rows - for whatever situation - and this is a shortish operation, I don't
think
a whole lot of users will mind that the server is slowish for 30 seconds.

All depends on the task at hand. But my first question would rather be:
do you really need to spend a lot of time to optimize this?

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com