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

> > Hmmm.... my question would then be, exactly how many Firebird
> > servers run on that sort of hardware? I would respectfully
> > suggest very few - RAID arrays for some, maybe.

> That may be correct, but the applications that need that level
> of performance tend to be the ones that can afford hardware.

Very true. It's kind of teleological really.

> > Well, part of my question was about whether the code was there
> > in the original IB6.0 release?


> No.

Ah, OK so - I thought that it might be just a "simple" matter
of activating hibernating code - that's obviously not the
case - I must have misconstrued what I saw.

> Often placement control is used to avoid disk head contention
> when doing indexed reads. Typical database access strategies
> require reading first from the index, then the data area to
> retrieve a record, then back to the index to identify the
> next target record, then back to the data area again.

Surely any system would build up a list? What system(s)
(well-known) use that strategy?

> Putting indexes on different disks reduces that head contention.

Indeed - but why one would want to use a "see-saw" strategy in
the first place baffles 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?

> Firebird (and InterBase) handle indexed access differently,
> first identifying all the qualifying index entries
> then accessing the data.

So, no advantage there then.

> > As I said, I have memories of
> > it being mentioned - it would be a "nice to have" and it
> > wouldn't just be performance - selective backups for example?


> The Interbase and Firebird philosophy says that a database is
> a group of related tables. That makes selective restore a
> non-issue. No one could work with a database that's half
> Thursday and half last Saturday.

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.

I worked in one shop where this problem was dealt with by
replicating the data onto a separate server for managers,
but putting the "old" data on a separate disk might help
if this wasn't an option? Until this was implemented, the
end of the month used to be hell for everybody!

> > Read only tablespaces?

> Unh, access control? What's the benefit of read only tablespaces?

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

> > It could be an option for advanced
> > users while maintaining the current configuration as the
> > default - it's just an idea that struck me. Performance will
> > not be an issue for me with my "briefcase" type app.


> Life is complicated enough without adding features for advanced
> users that don't have clear utility and performance benefits.

I'm not a big-time user of Firebird and neither am I an expert
programmer - and I bow to your (collective - you, Sean, Kjell &c.)
expertise in the area of Firebird usage. I'll consider myself
duly slapped around the head and told not to be such a
silly boy!!


Rgs to all,


Paul...

> Ann