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 a

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? > >   Theoret

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 p

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 you

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 FIELD.

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 some

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, w

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 repl

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 what

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 tablesp

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. Firebird-Deve

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 lik

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 pr

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 https://lists.sourceforge.net/lists/listinfo/

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 when

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 explana

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 lo

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 co

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? -- WBR

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 v

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

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 MAIN

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 f

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 so

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 co

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 we

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 consc

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 is

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 also

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 new

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' i

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 curr

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 magnitud

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 bi

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 avoid

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. PROPOSAL===

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 ID

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 w

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 keyword

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 well.

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 b

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 (ma

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 databas

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 "usually",

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 Firebi

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. A

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 partiti

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 a

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 e

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 on

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 https://lists.sourceforge.net/lists/listinfo/firebird

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 i

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 inde

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 p

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 of

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 serparatio

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 https://lists

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 th

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 lat

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 root

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 first

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

k 10: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&#x

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 RDB$POIN

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. Mayb

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 TABLESPACE

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 wi

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 sho

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 F

Re: [Firebird-devel] Tablespaces proposal

so they do not necessarily have to be on a quick-access disk. András -Original Message- From: Roman Simakov [mailto:roman.sima...@gmail.com] Sent: Wednesday, October 6, 2021 5:32 PM To: For discussion among Firebird Developers Subject: [Firebird-devel] Tablespaces proposal Hello, team!

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 a

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 https://lists.sourceforge.net

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 it

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 # intern

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 in

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 to

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 inte

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

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 prefer

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

  1   2   >