Re: [Firebird-devel] Tablespaces proposal

[Kjell Rilbe]

Den 2021-10-11 kl. 17:41, skrev Vlad Khorsun:
11.10.2021 15:17, Roman Simakov wrote:
Here is the second version of the proposal. It's taken into account 
all agreements we made during discussion and we'll do it in this way 
if there are no objections.

================PROPOSAL======================
GOALS
======
1) Extend the current limits on database size
2) Keep non active parts of a database on slow disks (having big volume)
3) Split indices from the database
etc

SYNTAX
=======

Note: *MAIN* - is a name of the basic database file.

  Please, use *DEFAULT* for default (main) tablespace at "main" 
database file.
It is much more consistent with SQL and allows to avoid new 
unnecessary keyword.

Good point, but from a natural language perspective, "default" seems to 
indicate the same as if that clause is left out. For indices in tables, 
that would be the table's tablespace, not the main database file. So the 
keyword "default" is not the best choice here i.m.h.o.

FILE can contain either an absolute path or a relative to the main 
database file.

3. *DROP TABLESPACE <TS NAME> [INCLUDING CONTENTS]*

If the tablespace contains some database objects the behaviour depends
on INCLUDING CONTENTS clause. if it is specified all database objects
in the tablespace will be dropped as well. Otherwise there will be an
error.

4. CREATE TABLE ...
(
...
FIELD TYPE CONSTRAINT ... USING INDEX ... *TABLESPACE {<TS NAME> | 
MAIN}*  -- field constraint tablespace
...
CONSTRAINT ... USING INDEX ... *TABLESPACE {<TS NAME> | MAIN}*  -- 
table constraint tablespace
...
)
*TABLESPACE <TS NAME>*

  Should we consider optional AT before TABLESPACE in all CREATE 
<object> [AT] TABLESPACE
<tsname> statements ? And, perhaps, optional TO in ALTER <object> SET 
TABLESPACE [TO] <tsname>.
Below I'll use both AT and TO, but not insist on it.
Again, from a natural language perspective, you put something IN 
(inside) a space, not AT (next to?) a space. So, if optional 
prepositions are introduced, I would recommend "in" rather than "at" in 
this case. But maybe this will cause problems considering other uses of 
the keyword "in" in SQL?

Page size is identical for every tablespace and the main database.

  Support for many page sizes requires changes in page cache 
management and should
be considered together. I don't see it as "must have" feature, btw.

That's the feature that our DB would benefit most from probably, since 
some tables are orders of magnitude(s) larger than most others, so to be 
able to have a larger page size for those tables' indices only would 
probably be nice.

Regards,
Kjell

<<attachment: kjell_rilbe.vcf>>Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel