Re: [Firebird-devel] Tablespaces proposal

On 6/2/22 14:45, Adriano dos Santos Fernandes wrote: On 02/06/2022 08:08, Dimitry Sibiryakov wrote: Alex Peshkoff via Firebird-devel wrote 02.06.2022 13:01:   It is "ALTER TABLE" which must be executed on replica. Otherwise you'll have problem with ALTER TABLE ADD FIELD. Is it impossible to

Re: [Firebird-devel] Tablespaces proposal

On 02/06/2022 08:08, Dimitry Sibiryakov wrote: > Alex Peshkoff via Firebird-devel wrote 02.06.2022 13:01: >>>   It is "ALTER TABLE" which must be executed on replica. Otherwise >>> you'll have problem with ALTER TABLE ADD FIELD. >> >> Is it impossible to analyze clauses of statement? > >  

Re: [Firebird-devel] Tablespaces proposal

Alex Peshkoff via Firebird-devel wrote 02.06.2022 13:01:   It is "ALTER TABLE" which must be executed on replica. Otherwise you'll have problem with ALTER TABLE ADD FIELD. Is it impossible to analyze clauses of statement? Theoretically - yes. On practice it would require full Firebird SQL

Re: [Firebird-devel] Tablespaces proposal

On 6/2/22 13:03, Dimitry Sibiryakov wrote: Alex Peshkoff via Firebird-devel wrote 02.06.2022 9:31: ALTER TABLE SET TABLESPACE is tablespaces-related DDL operator - i.e. it should not be executed on replica. Why conflict?   It is "ALTER TABLE" which must be executed on replica. Otherwise

Re: [Firebird-devel] Tablespaces proposal

Alex Peshkoff via Firebird-devel wrote 02.06.2022 9:31: ALTER TABLE SET TABLESPACE is tablespaces-related DDL operator - i.e. it should not be executed on replica. Why conflict? It is "ALTER TABLE" which must be executed on replica. Otherwise you'll have problem with ALTER TABLE ADD

Re: [Firebird-devel] Tablespaces proposal

On 6/2/22 10:14, Ilya Eremin wrote: Hello! The last tablespaces proposal says: > Tablespaces are excluded from replication because it's physical layout > of a database and a replica may have another one. which means that tablespaces-related DDL operators won't be executed on a replica. But

Re: [Firebird-devel] Tablespaces proposal

Hello! The last tablespaces proposal says: > Tablespaces are excluded from replication because it's physical layout > of a database and a replica may have another one. which means that tablespaces-related DDL operators won't be executed on a replica. But some conflicts may happen, for example,

Re: [Firebird-devel] Tablespaces proposal

Hello! PROPOSAL v.3=== 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. 1.

Re: [Firebird-devel] Tablespaces proposal

13.10.2021 15:44, Dimitry Sibiryakov wrote: Vlad Khorsun wrote 13.10.2021 14:39: Due to this, I see no reason to replicate physical layout of master database to the replica. I.e. TABLESPACE-related statements should not be replicated at all, IMO. Other opinions ?   I fully agree with not

Re: [Firebird-devel] Tablespaces proposal

Vlad Khorsun wrote 13.10.2021 14:39: Due to this, I see no reason to replicate physical layout of master database to the replica. I.e. TABLESPACE-related statements should not be replicated at all, IMO. Other opinions ? I fully agree with not replicated "CREATE/ALTER/DROP TABLESPACE" but

Re: [Firebird-devel] Tablespaces proposal

13.10.2021 13:14, Dimitry Sibiryakov wrote:   About moving of tablespaces and objects between tablespaces: on primary site it succeeded, on synchronous replica it failed (and vice versa). How such situation is going to be handled? Tablespace is a concept about physical layout of data. It is

Re: [Firebird-devel] Tablespaces proposal

ср, 13 окт. 2021 г. в 15:25, Dimitry Sibiryakov : > Roman Simakov wrote 13.10.2021 14:20: > > I suppose you mean async replication. I guess like other errors, no? > >No, I meant exactly synch replication. "Other errors" in such cases > leads to > transaction rollback on both sides. Can

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 13.10.2021 14:20: I suppose you mean async replication. I guess like other errors, no? No, I meant exactly synch replication. "Other errors" in such cases leads to transaction rollback on both sides. Can tablespace moving to be rolled back? -- WBR, SD.

Re: [Firebird-devel] Tablespaces proposal

ср, 13 окт. 2021 г. в 13:15, Dimitry Sibiryakov : >About moving of tablespaces and objects between tablespaces: on primary > site > it succeeded, on synchronous replica it failed (and vice versa). How such > situation is going to be handled? > I suppose you mean async replication. I guess

Re: [Firebird-devel] Tablespaces proposal

Den 2021-10-12 kl. 14:05, skrev Dmitry Yemanov: 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

Re: [Firebird-devel] Tablespaces proposal

About moving of tablespaces and objects between tablespaces: on primary site it succeeded, on synchronous replica it failed (and vice versa). How such situation is going to be handled? -- WBR, SD. Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 12.10.2021 16:30: 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

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] 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] 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] 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

Re: [Firebird-devel] Tablespaces proposal

11.10.2021 22:22, Lucas Schatz wrote: Just to clarify, the use of tablespace will be optional, right? Sure. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Tablespaces proposal

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

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 11.10.2021 20:23: > pag_header in every tablespace is reserved and may be replaced by a > new page type.    You mean page zero, which is currently always pag_header. I see no reason to change this, so far. Header page uses to describe properties of

Re: [Firebird-devel] Tablespaces proposal

11.10.2021 19:24, Dmitry Yemanov wrote: 11.10.2021 18:41, Vlad Khorsun wrote: 2. *ALTER TABLESPACE FILE '/path/to/file'*    In DDL, ALTER usually combined with ADD | SET | DROP, so let follow this convention. I.e. ALTER TABLESPACE SET FILE '/path/to/file' I'm not so sure about

Re: [Firebird-devel] Tablespaces proposal

Just to clarify, the use of tablespace will be optional, right? Anyway it would be a great improvement to Fb! Thanks! On Wed, Oct 6, 2021 at 12:33 PM Roman Simakov wrote: > Hello, team! > > As you might know Red Soft has implemented Tablespace support for > RedDatabase 4 which is based on

Re: [Firebird-devel] Tablespaces proposal

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 new unnecessary keyword. I'd be happy to agree.

Re: [Firebird-devel] Tablespaces proposal

> > > >Two ID's is reserved for DEFAULT and TEMPORARY tablespaces, correct ? > > I would reserve some more ID's for future system usage. I don't see it as > > limitation for end users. > > For regular tablespaces (created explicitly) - sure. But if we think > about automatically created

Re: [Firebird-devel] Tablespaces proposal

пн, 11 окт. 2021 г. в 18:42, Vlad Khorsun : > 11.10.2021 15:17, Roman Simakov wrote: > > 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

Re: [Firebird-devel] Tablespaces proposal

Dmitry Yemanov wrote 11.10.2021 18:24: It's possible to create up to 253 tablespaces.    Two ID's is reserved for DEFAULT and TEMPORARY tablespaces, correct ? I would reserve some more ID's for future system usage. I don't see it as limitation for end users. For regular tablespaces (created

Re: [Firebird-devel] Tablespaces proposal

11.10.2021 18:41, Vlad Khorsun wrote: 2. *ALTER TABLESPACE FILE '/path/to/file'*   In DDL, ALTER usually combined with ADD | SET | DROP, so let follow this convention. I.e. ALTER TABLESPACE SET FILE '/path/to/file' I'm not so sure about "usually", e.g. ALTER INDEX INACTIVE, ALTER DOMAIN

Re: [Firebird-devel] Tablespaces proposal

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

Re: [Firebird-devel] Tablespaces proposal

On 11/10/2021 09:17, Roman Simakov wrote: > > nbackup support is postponed. What do you mean? Both features are supposed to be more used by big databases, so they must work together. Adriano Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 11.10.2021 15:23: Cannot be tablespace identification loaded from RDB$INDEXES? Adding it into irp will increase size of irt_repeat by 1/3 decreasing limit of indexes per table, no? I'm sure the answer is the same as why the root page cannot be loaded from RDB$INDEXES

Re: [Firebird-devel] Tablespaces proposal

пн, 11 окт. 2021 г. в 16:14, Dimitry Sibiryakov : > > Roman Simakov wrote 11.10.2021 14:52: > >>> Add page space id to page number in ods.h:index_root_page. > >>> pag_root is located in the tablespace where a table is located > >> Why is this difference? What does prevent you from putting irp

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 11.10.2021 14:52: Add page space id to page number in ods.h:index_root_page. pag_root is located in the tablespace where a table is located Why is this difference? What does prevent you from putting irp into the tablespace where index is located? IRP describes every

Re: [Firebird-devel] Tablespaces proposal

пн, 11 окт. 2021 г. в 15:27, Dimitry Sibiryakov : > > Roman Simakov wrote 11.10.2021 14:17: > > FIELD TYPE CONSTRAINT ... USING INDEX ... TABLESPACE { | MAIN} -- > > field constraint tablespace > >What's the point of using "MAIN" here? Whole TABLESPACE clause cannot be > omitted? > > > Add

Re: [Firebird-devel] Tablespaces proposal

Dimitry Sibiryakov wrote 11.10.2021 14:26:   What's the point of using "MAIN" here? Nevemind, I've found the answer. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 11.10.2021 14:17: FIELD TYPE CONSTRAINT ... USING INDEX ... TABLESPACE { | MAIN} -- field constraint tablespace What's the point of using "MAIN" here? Whole TABLESPACE clause cannot be omitted? Add page space id to page number in ods.h:index_root_page. pag_root is

Re: [Firebird-devel] Tablespaces proposal

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

Re: [Firebird-devel] Tablespaces proposal

Den 2021-10-07 kl. 10:56, skrev Molnár Attila: "Tablespaces has meaning for large databases only that don't fit into single storage (terrabytes)." That is not true. It has meaning whatever the programmers meant to use it. It might not be about read performance, but e.g. logical data

Re: [Firebird-devel] Tablespaces proposal

чт, 7 окт. 2021 г. в 17:12, Mark Rotteveel : > > On 07-10-2021 15:54, Roman Simakov wrote: > > чт, 7 окт. 2021 г. в 11:14, Mark Rotteveel : > >> I think it will save a lot of headaches if ALTER DATABASE {BEGIN|END} > >> BACKUP can do that for all tablespaces at once. It would be a lot > >> simpler

Re: [Firebird-devel] Tablespaces proposal

Mark Rotteveel wrote 07.10.2021 16:11: Backing up only one tablespace could lead to inconsistent restores though. From practical POV it is not different from current partial backup including only subset of tables. -- WBR, SD. Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 07.10.2021 16:08: Let's eat an elephant one bite at a time Yes, that's exactly my point: no need to reserve fields if implementation that use them is not clear yet and better no feature than provisory hack. -- WBR, SD. Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Tablespaces proposal

On 07-10-2021 15:54, Roman Simakov wrote: чт, 7 окт. 2021 г. в 11:14, Mark Rotteveel : I think it will save a lot of headaches if ALTER DATABASE {BEGIN|END} BACKUP can do that for all tablespaces at once. It would be a lot simpler than having to arrange that per tablespace. That is not to say

Re: [Firebird-devel] Tablespaces proposal

чт, 7 окт. 2021 г. в 11:47, Dimitry Sibiryakov : > > Roman Simakov wrote 06.10.2021 21:49: > >> How are data moved? > >> > >> Under transaction control? > >> > >> In background (and interruptible) like db crypt? > > it's a dfw operation with EX database lock. I hope to relax this > > limitation

Re: [Firebird-devel] Tablespaces proposal

чт, 7 окт. 2021 г. в 11:45, Dimitry Sibiryakov : > > Roman Simakov wrote 07.10.2021 8:14: > > ср, 6 окт. 2021 г. в 23:57, Dimitry Sibiryakov: > >> Roman Simakov wrote 06.10.2021 22:44: > >>> Sorry I was wrong. TABLESPACE_ID is used as pagespace ID internally > >>> but this id presents at index

Re: [Firebird-devel] Tablespaces proposal

чт, 7 окт. 2021 г. в 11:14, Mark Rotteveel : > > On 2021-10-06 21:37, Roman Simakov wrote: > > ср, 6 окт. 2021 г. в 19:29, Adriano dos Santos Fernandes > > : > > >> And what about nbackup? Will it create a .delta file per tablespace? > > > > Our implementation does not support nbackup yet. At

Re: [Firebird-devel] Tablespaces proposal

чт, 7 окт. 2021 г. в 11:11, Mark Rotteveel : > > On 2021-10-06 21:27, Roman Simakov wrote: > > ср, 6 окт. 2021 г. в 19:13, Mark Rotteveel : > >> On 06-10-2021 17:32, Roman Simakov wrote: > >> > 9. ALTER INDEX DROP TABLESPACE > >> > > >> > Data of the index will be moved to the main database. > >>

Re: [Firebird-devel] Tablespaces proposal

Molnár Attila wrote 07.10.2021 10:56: It might not be about read performance, but e.g. logical data serparation, backup speedup, etc... Logical data separation is task for namespaces, not tablespaces. Physical backup of single tablespace is pointless because it has no TIP so without main

Re: [Firebird-devel] Tablespaces proposal

47 Címzett: For discussion among Firebird Developers Tárgy: Re: [Firebird-devel] Tablespaces proposal Roman Simakov wrote 06.10.2021 21:49: >> How are data moved? >> >> Under transaction control? >> >> In background (and interruptible) like db crypt? > it's a

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 06.10.2021 21:49: How are data moved? Under transaction control? In background (and interruptible) like db crypt? it's a dfw operation with EX database lock. I hope to relax this limitation later. So there are no concurrent changes. 1) copy all data pages 2) switch

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 07.10.2021 8:14: ср, 6 окт. 2021 г. в 23:57, Dimitry Sibiryakov: Roman Simakov wrote 06.10.2021 22:44: Sorry I was wrong. TABLESPACE_ID is used as pagespace ID internally but this id presents at index root page for example. I don't see it in ods.h:index_root_page.

Re: [Firebird-devel] Tablespaces proposal

On 2021-10-06 21:37, Roman Simakov wrote: ср, 6 окт. 2021 г. в 19:29, Adriano dos Santos Fernandes : And what about nbackup? Will it create a .delta file per tablespace? Our implementation does not support nbackup yet. At first glance it might be a special DDL operation like ALTER

Re: [Firebird-devel] Tablespaces proposal

On 2021-10-06 21:27, Roman Simakov wrote: ср, 6 окт. 2021 г. в 19:13, Mark Rotteveel : On 06-10-2021 17:32, Roman Simakov wrote: > 9. ALTER INDEX DROP TABLESPACE > > Data of the index will be moved to the main database. How will this work for indexes backing constraints? I see no problems

Re: [Firebird-devel] Tablespaces proposal

-devel@lists.sourceforge.net Cc: Simonov Denis Subject: Re: [Firebird-devel] Tablespaces proposal Omacht András писал(а) в своём письме Thu, 07 Oct 2021 09:18:26 +0300: > Hi Roman! > > First of all, thanks for the development and offering it to Firebird. > > Do you plan to par

Re: [Firebird-devel] Tablespaces proposal

Omacht András писал(а) в своём письме Thu, 07 Oct 2021 09:18:26 +0300: Hi Roman! First of all, thanks for the development and offering it to Firebird. Do you plan to partition the data depending on field value? Oracle range partitioning example: It seems to me that PARTITION support

Re: [Firebird-devel] Tablespaces proposal

чт, 7 окт. 2021 г. в 09:19, Omacht András : > > Hi Roman! > > First of all, thanks for the development and offering it to Firebird. Thanks) > Do you plan to partition the data depending on field value? Yes. We do. I hope we'll do something in the next version of RedDatabase and then share with

Re: [Firebird-devel] Tablespaces proposal

] Sent: Wednesday, October 6, 2021 5:32 PM To: For discussion among Firebird Developers Subject: [Firebird-devel] Tablespaces proposal Hello, team! As you might know Red Soft has implemented Tablespace support for RedDatabase 4 which is based on Firebird 4 code base. I hope we start working

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 23:57, Dimitry Sibiryakov : > > Roman Simakov wrote 06.10.2021 22:44: > > Sorry I was wrong. TABLESPACE_ID is used as pagespace ID internally > > but this id presents at index root page for example. > >I don't see it in ods.h:index_root_page. Maybe because I haven't made

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 06.10.2021 22:44: Sorry I was wrong. TABLESPACE_ID is used as pagespace ID internally but this id presents at index root page for example. I don't see it in ods.h:index_root_page. -- WBR, SD. Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Tablespaces proposal

> >ID is not referenced anywhere and seems to have no purpose at all. > > Probably it could be removed and pagespace IDs will be generated internally. Sorry I was wrong. TABLESPACE_ID is used as pagespace ID internally but this id presents at index root page for example. Now I'm not sure if

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 22:17, Dimitry Sibiryakov : > > Roman Simakov wrote 06.10.2021 20:43: > > Let me not describe every field. I hope most of them are obvious. > >No, they aren't. ok A new table RDB$TABLESPACES # keeps metadata of tablespaces. RDB$TABLESPACE_ID - SMALLINT #

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 22:48, Dimitry Sibiryakov : > > Roman Simakov wrote 06.10.2021 21:27: > > So am I. Currently tablespace headers are just not used. > >In this case how do you determine page size inside of tablespace file? > Having > it different from main one is an essential feature for

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 22:01, Adriano dos Santos Fernandes : > > On 06/10/2021 15:43, Roman Simakov wrote: > > > >>> RDB$POINTER_PAGE - INTEGER > >>> RDB$ROOT_PAGE - INTEGER > >> > >>What these are for? > > > > These fields are necessary for reliable implementation of moving data > > pages

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 06.10.2021 21:27: So am I. Currently tablespace headers are just not used. In this case how do you determine page size inside of tablespace file? Having it different from main one is an essential feature for indexes. -- WBR, SD. Firebird-Devel mailing list, web

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 19:29, Alex Peshkoff via Firebird-devel : > > On 10/6/21 6:32 PM, Roman Simakov wrote: > > > 4. CREATE TABLE … > > TABLESPACE > > Given syntax does not let specify tablespace for constraints-related > indexes and separate fields. That's serious limitation. At least for >

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 19:29, Adriano dos Santos Fernandes : > > On 06/10/2021 13:12, Mark Rotteveel wrote: > >> > >> Logical restore > >> > >> gbak -c -TABLESPACE_MAP(PING_FILE) /path/to/file/map/tablespaces > >> > >> The option TABLESPACE_MAP(PING_FILE) specifies a path to the

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 19:13, Mark Rotteveel : > > On 06-10-2021 17:32, Roman Simakov wrote: > > 3. DROP TABLESPACE [INCLUDING CONTENTS] > > I think using {CASCADE | RESTRICT} instead of [INCLUDING CONTENTS] would > be better, as that fits with similar definitions in the SQL standard > (e.g. 11.2 ,

Re: [Firebird-devel] Tablespaces proposal

Roman Simakov wrote 06.10.2021 20:43: Let me not describe every field. I hope most of them are obvious. No, they aren't. ID is not referenced anywhere and seems to have no purpose at all. TABLESPACE_NAME being CHAR is pointless. CHAR was used in ancient times but new fields should

Re: [Firebird-devel] Tablespaces proposal

On 06/10/2021 15:43, Roman Simakov wrote: > >>> RDB$POINTER_PAGE - INTEGER >>> RDB$ROOT_PAGE - INTEGER >> >>What these are for? > > These fields are necessary for reliable implementation of moving data > pages to another tablespace. You'll be able to understand their > meaning in code. >

Re: [Firebird-devel] Tablespaces proposal

ср, 6 окт. 2021 г. в 18:56, Dimitry Sibiryakov : > > Roman Simakov wrote 06.10.2021 17:32: > > A new table RDB$TABLESPACES: > > > > RDB$TABLESPACE_ID - SMALLINT > > RDB$TABLESPACE_NAME - CHAR (63) > > RDB$SECURITY_CLASS - CHAR (63) > > RDB$SYSTEM_FLAG - SMALLINT > > RDB$DESCRIPTION -

  1   2   >