"Ann W. Harrison" <aharrison@...> wrote:

> > Indeed - but why one would want to use a "see-saw" strategy in
> > the first place baffles me.

> It has the advantage that results are returned in index order,
> which is nice if you're doing something like

> select first 1 first_name, last_name
> from everybody_in_the_USA
> order by last_name;

Surely this could be done by the simple expedient of getting all
the necessary record pointers first, and then sorting that small
list and then getting those records in the order of the
sorted small list? I'm not a database programming expert and
if my naïvity makes you shake your head in pity, then please
forgive me.

> > What about when the database is responding to concurrent requests,
> > one on one table, one on another? It might be useful then to
> > have a possible data-placement strategy - depending on the
> > disk/table usage profile of the app?


> Really, RAID and a big cache are a much better solution for
> that case.

OK.

> > Archive data older than a month on a read-only separate
> > tablespace - might help "partition" those doing day-to-day
> > work (OLTP - data entry) and managers doing OLAP/DW work,
> > reports &c. and avoid contention between the two.


> Well, maybe. I have a hard time imagining a well-written
> Firebird application on modern hardware being unable to do
> end-of-month and analysis simultaneously.

I thought the literature about databases was full of the
OLTP/OLAP conflict - separating such tables onto different
disks would, I thought, have helped? But, you're saying RAID...


One final point about the advantage of separation and then
I'll shut up, never to be heard mentioning this topic
again.

Oracle (the kitchen sink implementation to beat all kitchen
sink implementations) does have one good thing going for it,
it is very well instrumented compared to other RDBMS's.

Would separating the data from different tables onto different
disks not give the tuning engineer a better chance to be able
to figure out where their database was spending time during
a (unacceptably) long-running query?

> > See above - also read-only tablespaces incur no transactional
> > overhead.

> Sure they do. Or more precisely, a read-only table space
> in a read-write database has exactly the same transactional
> overhead as an inactive section of a table.

> Do keep asking questions...

Will do - and thanks to everyone on the group for being so

1) patient and

2) informative


It's nice to see that the word "community" isn't just some
marketing babble.


Paul...