How do we map the logical table to the tablespace?
Does Postgres automatically creates tablespaces when we create a table or a schema?
Tablespaces and schemas are independent from each other: the first concerns the physical placement of the table, the second the namespace.
PostgreSQL automatically creates a tablespace: it is called pg_default and is located in the base subdirectory of the data directory.
All tables you create are placed there unless:
You use the TABLESPACE clause of CREATE TABLE to place it elsewhere.
The table is in a database with a different tablespace.
You set the default_tablespace parameter to a different tablespace.
Tablespaces are rarely needed, and usually it is best to keep all tables in the default tablespace.
Related
Can we change data directory for single table or database in postgresql.
Actually my requirement is that I want to keep all tables data in C drive but customers table data in D drive. how to achieve this?
You should create a tablespace for the tables outside the data directory.
For example:
CREATE TABLESPACE tbsp LOCATION 'D:\customer_tables';
Then add TABLESPACE tbsp to all CREATE TABLE statements that should be on D.
We have got some DDLs for our schema. These DDLs create tables and indexes in a given tablespace. Something like:
CREATE TABLE mySchema.myTable
(
someField1 CHAR(2) NOT NULL ,
someField2 VARCHAR(70) NOT NULL
)
IN MY_TBSPC
INDEX IN MY_TBSPC;
We want to reuse this DDLs to run some integration tests using APACHE DERBY. The problem is that such syntax is not accepted by DERBY. Is there any way to define a kind of default tablespace for tables and indexes, so we can remove this 'IN TABLESPACE' statements.
There is no deterministic way of defining a "default" tablespace in DB2 (I'm assuming we're dealing with DB2 for LUW here). If the tablespaces are not explicitly indicated in the CREATE TABLE statement, the database manager will pick for table data the first tablespace with the suitable page size that you are authorized to use, and indexes will be stored in the same tablespace as data.
This means that if you only have one user tablespace it will always be used for both data and indexes, so in a way it becomes the default. However, if you have more than one tablespace with different page sizes you may end up with tables (and their indexes) in different tablespaces.
For one of my issue, I am trying to understand the functionalities of below DB2 entities,
System Temporary table space.
Page Size.
Table Space.
Buffer Pool.
And below is my observation,
There is a TableSpace linked to a table in the DB2 table syscat.tables
The TableSpaces are linked to BufferPool with the relation defined in syscat.tablespaces
System Temporary table space is the table space that the DB might use while executing the query.
Page Size is an unit that defines the limit of a TableSpace and says how much data can a TableSpace can hold.
Is there something wrong in my above understandings? And when I excute a query how does the DB chooses which TableSpace to choose?
I am creating a table with tablespace:
CREATE TABLE SALARY.....
IN ACCOUNTING INDEX IN ACCOUNT_IDX
Where will the Accounting and Account_IDX be created?
The script that you have above will create SALARY in the ACCOUNTING tablespace, with indexes for that table in ACCOUNT_IDX tablespace.
The ACCOUNTING and ACCOUNT_IDX tablespaces need to be created in a separate script that has CREATE TABLESPACE statements.
If you look at the syntax for CREATE TABLESPACE, the USING part of the statement will tell DB2 where to put the files for the tablespace.
DB2 Create Tablespace Reference
I have a table X in tablespace T1 and a table Y in tabelspace T2.(Oracle DB)
I have to create a trigger in tablespace T1 that will,
on the event of updating a column C in table X,
update column D in table Y (tablespace T2).
Because they are in different tablespaces, my first question is can this be done at all?
And if yes then how it can be done? What privileges are required to do such a thing?
It has not so much to do with the tablespace. You do need privileges to insert into the table (and that particular column) though, and if the table Y is in another schema than the trigger, you need to use the qualified table name: . (In Oracle, the schemaname is the name of the user that owns the object)
CREATE TRIGGER aur_x
AFTER UPDATE OF c ON x
FOR EACH ROW
UPDATE schema_containing_y.Y SET D = ...
;
EDIT:
It just occurred to me that you might not be familiar with the distinction between schema and tablespace, so here's a short explanation. A tablespace is a logical storage container: it dedfines datafiles, growth characteristics, logging types etc. Tablespaces can then be used as to store data associated with schema objects (tables, indexes, views definitions, but also packages and stored procedure definitions etc).
A schema is a collection of objects (like tables, views, pacakages etc.) These objects are owned by a user, and as far as i am aware, in oracle the schema has an name identical to the user that owns the objects. THe objects rely on the storage provided by one or more tablespaces, but tablespaces themselves are not schema objects.
Typically, a schema is used to group functionally related objects (for example, you'd typically create one schema for one application). Tablespaces can also be created especially to store all objects of one application, but you can also create different tablespaces for tables with different characteristics.
Normally, application developers shouldn't worry too much about tablespaces. Your DBA will typically set them up in a way that is convenient for things like backup plan.