Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 12.10.2021 17:51:> More details you will find in PR and then we will be able to discuss it. Actually we don't discuss. I just beg you for explanation why it was done this way, which alternatives were considered and why they were found unacceptable or worse. Such

Re: [Firebird-devel] Tablespaces proposal

Hi, From: Dimitry Sibiryakov [mailto:s...@ibphoenix.com] > 2) Keep non active parts of a database on slow disks (having big > volume) This part is meaningless because good storages provide storage tiering at block level. For You maybe meaningless, but believe me a lot of users will

Re: [Firebird-devel] Tablespaces proposal

вт, 12 окт. 2021 г. в 18:27, Dimitry Sibiryakov : > > Roman Simakov wrote 12.10.2021 17:16: > > I'm not sure that keeping page numbers in a transactional relation is > > a really excellent idea. > >But you added it into RDB$RELATIONS table, no?.. It does not make sense to discuss it without

Re: [Firebird-devel] Tablespaces proposal

Dmitry Yemanov wrote 12.10.2021 17:34: They're modified in user transaction(s). Nevertheless users have no right for direct modifications so they cannot mess with the page number value. If we exclude the field from the query inside of AlterXXX methods it should to be safe, right? --

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 18:26, Dimitry Sibiryakov wrote: System tables are operated in system transaction They're modified in user transaction(s). Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 12.10.2021 17:16: I'm not sure that keeping page numbers in a transactional relation is a really excellent idea. But you added it into RDB$RELATIONS table, no?.. System tables are operated in system transaction which effectively uses TIL dirty read so there is no real

Re: [Firebird-devel] Tablespaces proposal

вт, 12 окт. 2021 г. в 18:03, Dimitry Sibiryakov : > > Roman Simakov wrote 12.10.2021 16:55: > >> If this field is needed at all. Still there is no answer why tablespace > >> cannot be identified by name only except "it was done this way 40 years > >> ago". > > Why not to suggest PR for this

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 13:57, Kjell Rilbe wrote: Den 2021-10-12 kl. 08:09, skrev Roman Simakov: пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun mailto:hv...@optima.com.ua>>:     11.10.2021 21:23, Roman Simakov wrote:     > пн, 11 окт. 2021 г. в 18:42, Vlad Khorsun mailto:hv...@optima.com.ua>

Re: [Firebird-devel] Tablespaces proposal

вт, 12 окт. 2021 г. в 18:07, Vlad Khorsun : > > 12.10.2021 17:53, Roman Simakov wrote: > > вт, 12 окт. 2021 г. в 13:11, Vlad Khorsun : > >> > >> 12.10.2021 9:09, Roman Simakov wrote: > >>> пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun >>> >: > > ... > > >>> > But

Re: [Firebird-devel] Partitioning

Dmitry Yemanov wrote 12.10.2021 16:59: Slightly faster inserts into indices. If local indexes are used, yes. But such indexes require partitioning key in queries. What will be effect for global indexes? Reference to the partition for a record has to be in index node, no? But it may be

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 17:53, Roman Simakov wrote: вт, 12 окт. 2021 г. в 13:11, Vlad Khorsun : 12.10.2021 9:09, Roman Simakov wrote: пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun mailto:hv...@optima.com.ua>>: ... > But MAIN exactly specifies the database itself. We especially have removed DEFAULT

Re: [Firebird-devel] Tablespaces proposal

вт, 12 окт. 2021 г. в 18:01, Adriano dos Santos Fernandes : > > In the context of Firebird, IMO it seems weird to have a SYSTEM > tablespace where user objects are put. > > It makes it appear that it would be related to system objects. > > I prefer PRIMARY. I see that most people prefer PRIMARY

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 12.10.2021 16:55: If this field is needed at all. Still there is no answer why tablespace cannot be identified by name only except "it was done this way 40 years ago". Why not to suggest PR for this refactoring? I understand that you insist on merging your existing

Re: [Firebird-devel] Tablespaces proposal

On 12/10/2021 11:53, Roman Simakov wrote: >> >>SYSTEM (best) or PRIMARY, imho. > > Oracle's SYSTEM tablespace contains server-wide objects but not only > database ones. But for now I agree we have two the most suitable > options: SYSTEM, PRIMARY. > In the context of Firebird, IMO it seems

Re: [Firebird-devel] Partitioning (was: Tablespaces proposal)

12.10.2021 16:21, Dimitry Sibiryakov wrote:   INSERT:   Nothing except time wasting to calculation partitioning key and creation of a new partition if necessary (ignorable). Slightly faster inserts into indices.   UPDATE:   DELETE: Faster index GC after them.   BACKUP: Backup of

Re: [Firebird-devel] Tablespaces proposal

вт, 12 окт. 2021 г. в 13:17, Dimitry Sibiryakov : > > Vlad Khorsun wrote 12.10.2021 12:10: > >> I see no problem with increasing the limit. I see problems with reducing it > >> (someone may use them). So let's start from a small number 63. When we > >> implement partitions we increase it more

Re: [Firebird-devel] Tablespaces proposal

вт, 12 окт. 2021 г. в 13:11, Vlad Khorsun : > > 12.10.2021 9:09, Roman Simakov wrote: > > пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun > >: > > > > 11.10.2021 21:23, Roman Simakov wrote: > > > I'd be happy to agree. Actually we took a look at Oracle syntax. The

Re: [Firebird-devel] Tablespaces proposal

вт, 12 окт. 2021 г. в 11:56, Mark Rotteveel : > > On 11-10-2021 14:17, Roman Simakov wrote: > [..] > > > SYNTAX > > === > [..] > > 3. *DROP TABLESPACE [INCLUDING CONTENTS]* > > > > If the tablespace contains some database objects the behaviour depends > > on INCLUDING CONTENTS clause. if it

Re: [Firebird-devel] Partitioning (was: Tablespaces proposal)

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

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 15:26, Dimitry Sibiryakov wrote: In this case your vision of partitioning is quite special because in others' implementations it has nothing to do with multiple files Partition is a page set. Different page sets may be surely stored inside a single database file, but they may

Re: [Firebird-devel] Tablespaces proposal

On 10/11/21 10:07 PM, Dimitry Sibiryakov wrote: Roman Simakov wrote 11.10.2021 20:23: > 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

Re: [Firebird-devel] Tablespaces proposal

Dmitry Yemanov wrote 12.10.2021 14:19: There's also 4th goal: provide internal infrastructure (splitting page spaces into multiple files) to support partitioning later. I expect these two features to share a lot. In this case your vision of partitioning is quite special because in others'

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 14:52, Dimitry Sibiryakov wrote: GOALS == 1) Extend the current limits on database size   Current limit is 16 TB and can be extended without explicit tablespace managing by something similar to OS memory mapping technique effectively adding some external-sourced bits to

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 13:36, Kjell Rilbe wrote: 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

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 11.10.2021 14:17: GOALS == 1) Extend the current limits on database size Current limit is 16 TB and can be extended without explicit tablespace managing by something similar to OS memory mapping technique effectively adding some external-sourced bits to current 32

Re: [Firebird-devel] Tablespaces proposal

Den 2021-10-11 kl. 21:07, skrev Dimitry Sibiryakov: Roman Simakov wrote 11.10.2021 20:23: > 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

Re: [Firebird-devel] Tablespaces proposal

Den 2021-10-12 kl. 08:09, skrev Roman Simakov: пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun >: 11.10.2021 21:23, Roman Simakov wrote: > пн, 11 окт. 2021 г. в 18:42, Vlad Khorsun mailto:hv...@optima.com.ua>

Re: [Firebird-devel] Tablespaces proposal

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.

Re: [Firebird-devel] Tablespaces proposal

Vlad Khorsun wrote 12.10.2021 12:10: I see no problem with increasing the limit. I see problems with reducing it (someone may use them). So let's start from a small number 63. When we implement partitions we increase it more consciously.   I speak about data type used in ODS for tablespace

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 12:02, Mark Rotteveel wrote: On 11-10-2021 17:41, Vlad Khorsun wrote: 11.10.2021 15:17, Roman Simakov wrote: 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

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 9:09, Roman Simakov wrote: пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun mailto:hv...@optima.com.ua>>: 11.10.2021 21:23, Roman Simakov wrote: > пн, 11 окт. 2021 г. в 18:42, Vlad Khorsun mailto:hv...@optima.com.ua> >>:

Re: [Firebird-devel] Tablespaces proposal

Mark Rotteveel wrote 12.10.2021 10:55: It allows you to restore tablespace contents to new places. If the option is not specified gbak will use old locations for every tablespace. I still think this should be an explicit option as well, otherwise surprising things - for the user - can happen

Re: [Firebird-devel] Tablespaces proposal

On 11-10-2021 17:41, Vlad Khorsun wrote: 11.10.2021 15:17, Roman Simakov wrote: 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

Re: [Firebird-devel] Tablespaces proposal

On 11-10-2021 14:17, Roman Simakov wrote: [..] SYNTAX === [..] 3. *DROP TABLESPACE [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

Re: [Firebird-devel] Tablespaces proposal

пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun : > 11.10.2021 21:23, Roman Simakov wrote: > > пн, 11 окт. 2021 г. в 18:42, Vlad Khorsun hv...@optima.com.ua>>: > > > > 11.10.2021 15:17, Roman Simakov wrote: > > > SYNTAX > > > === > > > > > > Note: *MAIN* - is a name of the