In MS SQL Server Temporary tables are stored in tempdb Database.
Is there a similar special place in GreenPlum for temporary tables? Or is a temp table just stored in the current database & schema under which I do normal transactions?
Temporary tables in Greenplum are stored in the database in which they were created, but in a temporary schema which lives for the duration of the session which created the table.
i.e.
[gpadmin#mdw:~] $ createdb temp
[gpadmin#mdw:~] $ psql temp
temp=# create temporary table test_temp(a int) distributed by (a);
CREATE TABLE
Time: 50.516 ms
temp=# \d
List of relations
Schema | Name | Type | Owner | Storage
------------+-----------+-------+---------+---------
pg_temp_11 | test_temp | table | gpadmin | heap
(1 row)
temp=# \dn
List of schemas
Name | Owner
--------------------+---------
gp_toolkit | gpadmin
information_schema | gpadmin
pg_aoseg | gpadmin
pg_bitmapindex | gpadmin
pg_catalog | gpadmin
pg_temp_11 | gpadmin
pg_toast | gpadmin
pg_toast_temp_11 | gpadmin
public | gpadmin
(9 rows)
temp=#
temp=# \q
[gpadmin#mdw:~] $ psql temp
Timing is on.
psql (8.3.23)
Type "help" for help.
temp=# \d
No relations found.
temp=# \dn
List of schemas
Name | Owner
--------------------+---------
gp_toolkit | gpadmin
information_schema | gpadmin
pg_aoseg | gpadmin
pg_bitmapindex | gpadmin
pg_catalog | gpadmin
pg_toast | gpadmin
public | gpadmin
(7 rows)
temp=#
Does this answer your question?
Related
[Question posted by a user on YugabyteDB Community Slack]
Does renaming the table, existing partitions attached to that table remain as it is after renaming?
Yes.
yugabyte=# \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------------+-------+----------
public | order_changes | table | yugabyte
public | order_changes_2019_02 | table | yugabyte
public | order_changes_2019_03 | table | yugabyte
public | order_changes_2020_11 | table | yugabyte
public | order_changes_2020_12 | table | yugabyte
public | order_changes_2021_01 | table | yugabyte
public | people | table | yugabyte
public | people1 | table | yugabyte
public | user_audit | table | yugabyte
public | user_credentials | table | yugabyte
public | user_profile | table | yugabyte
public | user_svc_account | table | yugabyte
(12 rows)
yugabyte=# alter table order_changes RENAME TO oc;
ALTER TABLE
yugabyte=# \dS+ oc
Table "public.oc"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
-------------+------+-----------+----------+---------+----------+--------------+-------------
change_date | date | | | | plain | |
type | text | | | | extended | |
description | text | | | | extended | |
Partition key: RANGE (change_date)
Partitions: order_changes_2019_02 FOR VALUES FROM ('2019-02-01') TO ('2019-03-01'),
order_changes_2019_03 FOR VALUES FROM ('2019-03-01') TO ('2019-04-01'),
order_changes_2020_11 FOR VALUES FROM ('2020-11-01') TO ('2020-12-01'),
order_changes_2020_12 FOR VALUES FROM ('2020-12-01') TO ('2021-01-01'),
order_changes_2021_01 FOR VALUES FROM ('2021-01-01') TO ('2021-02-01')
Postgres and therefore YugabyteDB doesn’t actually use the names of an object, it uses the OID (object ID) of an object.
That means that you can rename it, without actually causing any harm, because it’s simply a name in the catalog with the object identified by its OID.
This has other side effects as well: if you create a table, and perform a certain SQL like ‘select count(*) from table’, drop it, and then create a table with the same name, and perform the exact same SQL, you will get two records in pg_stat_statements with identical SQL text. This seems weird from the perspective of databases where the SQL area is shared. In postgres, only pg_stat_statements is shared, there is no SQL cache.
pg_stat_statements does not store the SQL text, it stores the query tree (an internal representation of the SQL), and symbolizes the tree, which makes to appear like SQL again. The query tree uses the OID, and therefore for pg_stat_statements the above two identical SQL texts are different query trees, because the OIDs of the tables are different.
I have the following structure for Users_Role table:
| role_id(PK) | role_name |
| ---------------| --------------|
| 1 | Admin |
| 2 | View |
And the following structure for Users table:
| user_id (PK) | user_role_id(FK) |
| -------------| --------------------|
| 12345 | 1 |
| 22434 | 1 |
The tables are connected by user_role_id and role_id
I want to create new records in Users Table, the thing is I only have the user_role value.
Is there a way to shortcut the way to get the value of the user_role_id, or the only way to do it is a seperate query before creating new record in Users?
const userRole = "Admin";
Users.create({
user_id:"1234",
user_role_id: ???
})
I have been stuck on this problem for a while now and cannot figure it out. Hoping someone can help me.
I think my situation is pretty simple, so I feel extra stupid for having to post this Nonetheless -- I have a database, lets call it tempdb, that was created by user ikaros on Postgres 13.3 (Ubuntu 13.3-1.pgdg16.04+1)
Here is the output from \l+ with irrelevant information omitted.
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace | Description
-----------------------+----------+----------+-------------+-------------+-----------------------+---------+------------+--------------------------------------------
...
ikaros | ikaros | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 8029 kB | pg_default |
tempdb | ikaros | UTF8 | C | C | =T/ikaros +| 13 GB | pg_default |
| | | | | ikaros=CTc/ikaros +| | |
| | | | | johndoe=CTc/ikaros | | |
...
Currently, johndoe can connect to the database tempdb, but when executing a query, gets a message about not having sufficient table level privilege's. Error: Unable to execute query: Fatal Error; Reason: Error: (ERROR: permission denied for table settings )
I want johndoe to have full read privilege's on the tempdb along with all tables inside. How can I go about that? Thanks in advance!
According to Postgres documents, You can use below queries to add permission to users:
-- This query used for access to the database
grant connect on database [YOUR_DATABASE] to [USERNAME];
-- This query used for access to the schema
grant usage on schema [SCHEMA1, SCHEMA2, ...] to [USERNAME];
-- This query is used for access to all tables of a schema (or can use just **select** instead of **all**
grant all on all tables in schema [SCHEMA1, SCHEMA2, ...] to [USERNAME];
grant select on all tables in schema [SCHEMA1, SCHEMA2, ...] to [USERNAME];
-- If need add select permission to a specific table
grant select on table [YOUR_SCHEMA].[YOUR_TABLE] to [USERNAME];
In cassandra (am using DSE),
how do I check how many users are connected to the database? Any way to check node wise?
Is there any auditing info stored which will tell me which all users connected along with info such as IP address and driver used etc?
In Opscenter there is a metric called "Native clients", where is this info stored in the db to query for? Does this include internal communication between the nodes and backups etc?
How do I check how many users are connected to the database? Any way to check node wise?
Is there any auditing info stored which will tell me which all users connected along with info such as IP address and driver used etc?
DSE has a performance service feature which you can enable to make this information available via cql. To enable this particular capability, configure the following in dse.yaml as described in the docs:
user_level_latency_tracking_options:
enabled: true
With this enabled, you can now query a variety of tables, for example:
cqlsh> select * from dse_perf.user_io;
node_ip | conn_id | last_activity | read_latency | total_reads | total_writes | user_ip | username | write_latency
-----------+-----------------+---------------------------------+--------------+-------------+--------------+-----------+-----------+---------------
127.0.0.1 | 127.0.0.1:55116 | 2019-01-14 14:08:19.399000+0000 | 1000 | 1 | 0 | 127.0.0.1 | anonymous | 0
127.0.0.1 | 127.0.0.1:55252 | 2019-01-14 14:07:39.399000+0000 | 0 | 0 | 1 | 127.0.0.1 | anonymous | 1000
(2 rows)
cqlsh> select * from dse_perf.user_object_io;
node_ip | conn_id | keyspace_name | table_name | last_activity | read_latency | read_quantiles | total_reads | total_writes | user_ip | username | write_latency | write_quantiles
-----------+-----------------+---------------+------------+---------------------------------+--------------+----------------+-------------+--------------+-----------+-----------+---------------+-----------------
127.0.0.1 | 127.0.0.1:55252 | s | t | 2019-01-14 14:07:39.393000+0000 | 0 | null | 0 | 1 | 127.0.0.1 | anonymous | 1000 | null
127.0.0.1 | 127.0.0.1:55116 | s | t | 2019-01-14 14:08:19.393000+0000 | 1000 | null | 1 | 0 | 127.0.0.1 | anonymous | 0 | null
Note that there is a cost to enabling the performance service, and it can be enabled and disabled selectively using dsetool perf userlatencytracking [enable|disable].
In a future release of Apache Cassandra (4.0+) and DSE (likely 7.0+), there will be a nodetool clientstats command (CASSANDRA-14275), and a corresponding system_views.clients table (CASSANDRA-14458) that includes connection info. This will include the driver name, if the driver client provides one (newer ones do).
In Opscenter there is a metric called "Native clients", where is this info stored in the db to query for? Does this include internal communication between the nodes and backups etc?
I'm not too up to speed on OpsCenter. From what I know OpsCenter typically stores it's data in the OpsCenter keyspace, you can configure data collection parameters by following this doc.
In our crawling system we have 5 node cassandra cluster. I have a scenario in which I want to delete cassandra data as soon as it becomes older than x days.
Ex:
id | name | created_date
1 | Dan | "2017-08-01"
2 | Monk | "2017-08-02"
3 | Shibuya | "2017-08-03"
4 | Rewa | "2017-08-04"
5 | Himan | "2017-08-05"
if x = 3 Then following should be the scenario:
id | name | created_date
1 | Dan | "2017-08-01" --------------> DELETE
2 | Monk | "2017-08-02" --------------> DELETE
3 | Shibuya | "2017-08-03" -------------->(REMAIN)Latest 3 days data
4 | Rewa | "2017-08-04" -------------->(REMAIN)Latest 3 days data
5 | Himan | "2017-08-05" -------------->(REMAIN)Latest 3 days data
If new data is added then id=3 should be deleted.
Is there any Cassandra configuration or any approach to do this?
Cassandra has a TTL feature, that allows you to specify how long each CQL cell is valid. Details are available on the INSERT docs, but it also applies to UPDATE.
You can use TTL.
But be careful with tombstouns and compaction procedure