Jim Starkey <jas@...> wrote:

>Boy, you ask a lot of questions.

Thanks for taking the time to answer them.

>The comparison was problem with non-synced IO, O_SYNC, and a raw
>file system (where Interbase runs just fine, thank you). I vaguely
>remember that sync-ed IO on SunOS was significantly slower than
>raw IO, which is always sync-ed. But it was a long time ago. If
>somebody cares, they could easily measure the difference.

That second level cache isn't really a benefit at all. O_SYNC must go
through the buffer cache, while raw devices bypass it all together; an
important difference.

>Unless somebody can come up with a better schema, a page version
>number at each is probably the best compromise, even if that's
>what SQL/Server does.

It's not just DEC and Microsoft. I believe Tandem and IBM also do it, and
I'm sure others do as well. Those checksums are expensive, and they don't
really help much over two flags.


[ On allocating space within a table for a new record ]

>No, it leads to unused space. Got a better idea that doesn't create
>hot spots?

More overflow pages than necessary and unused space are pretty much the same
thing.

An alternative might be using conventional data pages as overflow pages,
along with a better way for the engine to know how much free space is
available on data pages.

Of course, I haven't done any measurements, so I don't even know if this is
a big problem. Although from the original complaint (and the subject line on
this message) I suspect it might be.

Jan Mikkelsen
janm@...