Dmitry Yemanov wrote 12.10.2021 15:02:
Partition is a page set. Different page sets may be surely stored inside a
single database file, but they may also be stored in different files. It makes a
lot of sense to nbackup only some partition(s), or store them on slow drives,
etc -- the same as for tablespaces.
Ok, let's talk about it a little.
Lets' define partitioning as "a split of table into pieces according to some
condition". Call this condition "a partitioning key".
What benefits can it have to database operations?
SELECT:
If query condition match partitioning key then natural scan can be reduced to
subset of pages. This is effect similar to IOT.
Local index can be used that have smaller depth and size.
Parallel reading of different partitions... not going to happen.
INSERT:
Nothing except time wasting to calculation partitioning key and creation of a
new partition if necessary (ignorable).
UPDATE:
Effectively become INSERT+DELETE if partitioning key is changed, otherwise
nothing.
DELETE:
Can be reduced to TRUNCATE if the only query condition matches partitioning
condition.
BACKUP:
Backup of separate partition is something nobody asked for so far. At least I
cannot remember a ticket for gbak accepting filter condition inside of a table,
only filter for whole tables and (since it is already implemented)... is anybody
aware of it?..
RESTORE:
How backup of single partition is supposed to be restored or otherwise used?
PS: The case of slow drives was already commented. It is an internal feature of
modern hybrid storage systems and Firebird doesn't need another "hand-made RAID".
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
