MM == Mike Matrigali [EMAIL PROTECTED] writes:
MM Derby will also reclaim space automatically in btree indexes for this
MM case as long as all the old rows on a given leaf are deleted and
MM the background process gets a chance to get a table level lock
MM at some point - the
Mike Matrigali wrote:
The split description below describes Derby behavior.
Derby does not merge almost empty pages - only empty pages.
Derby maintains a separate file per table and a separate file
per index. Derby maintains a free page pool per file and only
can use the free pages in the same
Edson Carlos Ericksson Richter wrote:
Thanks for fast response.
I think the reason Derby didn't used any index is because since this
table, for my tests purposes has only one record, I've not created any
index at all.
I suspect that one record table will be in cache for a long time
(since
Yes, that's what I have in mind.
See, if I issue a very large, expensive select * from huge_table, if I
have server side cursors, response is immediate, because there is
nothing to process. My cursor is just a pointer to real data in the table.
Even if I make a select * from huge_table order
. . . if I issue a very large, expensive select * from huge_table, if I
have server side cursors, response is immediate, because there is nothing
to process. My cursor is just a pointer to real data in the table.
Even if I make a select * from huge_table order by some_column, if the
column
