I recently deployed a flask-postgresql based app on heroku, I am quite surprised that with just 1 row of data in table the data size is 7.3 as shown in the postgresql database dashboard on heroku.
::DATABASE=> \d messages;
Table "public.messages"
Column | Type | Modifiers
----------+-----------------------------+-----------------------------------------------------------
msg_id | integer | not null default nextval('messages_msg_id_seq'::regclass)
fullName | character varying(60) |
message | character varying |
ip | character varying(20) |
done | boolean |
pub_date | timestamp without time zone |
Indexes:
"messages_pkey" PRIMARY KEY, btree (msg_id)
you use psql meta-commands - modify them a little and you will get the size:
\dt+ messages will give you the size of relation
\l+ database_name will show the size of database
Related
I want to show something like this with PostgreSQL but I don't know what I must searching for
can you explain to me how to show something like this with PostgreSQL ?
The image you shared is a graphical layout of tables. PostgreSQL doesn't produce such output, but you can get the layout of individual tables by running \d <tablename> in psql. This will provide you with the list of columns, column types, constraints, primary key, foreign keys and comments.
For example:
postgres=# \d catalogue
Table "public.catalogue"
Column | Type | Collation | Nullable | Default
-------------+---------+-----------+----------+---------------------------------------
id | integer | | not null | nextval('catalogue_id_seq'::regclass)
item | name | | |
qty | integer | | |
description | text | | |
Indexes:
"catalogue_pkey" PRIMARY KEY, btree (id)
Alternatively, if you require a GUI-based solution, check out PgAdmin: https://www.pgadmin.org/
You can use dbeaver for this, using View Diagram option clicking in you schema
I have a table with schema :
Table: "public.system_configuration_parameter"
Column | Type | Collation | Nullable | Default
---------------+-----------------------------+-----------+----------+--------------------------------------------------
id | integer | | not null | nextval('system_configuration_id_seq'::regclass)
name | character varying | | not null |
type | character varying | | not null |
value | character varying | | |
default_value | character varying | | not null |
date_added | timestamp without time zone | | not null | now()
date_modified | timestamp without time zone | | not null | now()
Indexes:
"system_configuration_parameter_pkey" PRIMARY KEY, btree (id)
"system_configuration_parameter_name_key" UNIQUE CONSTRAINT, btree (name)
The following query results into ERROR:
insert into system_configuration_parameter (name, type, value ,default_value) values ('serverPerformanceMode','String','standardMode','standardMode');
ERROR: duplicate key value violates unique constraint "system_configuration_parameter_name_key"
DETAIL: Key (name)=(serverPerformanceMode) already exists.
The thing is there is no entry present in a table with name value as 'serverPerformanceMode'
shubhdb=# select value from system_configuration_parameter where name = ('serverPerformanceMode');
(0 rows)
I am using postgres 9.3, I have performed a migration of postgres to upgraded version 10. I currently have both the versions installed in my system.
I used to use the same database with the same structure and it used to work perfectly fine before. This even works fine with postgres-10 now, the problem occurs only when I use postgres-9.3 with the same build.
Does anyone have any idea about this? or has faced the same issue?
Thank you for reading.
This type of problem is usually caused by user error. You are probably connecting to one database to do the insert, and a different one to do the query (or perhaps different schema's of the same database). Can you make your code which does the insertion follow-up the error by running the query, using the same connection object, rather than running the query manually over a different connection?
I need to cast varchar to json using:
CREATE CAST (character varying AS json) WITHOUT FUNCTION as ASSIGNMENT;
Connecting to Postgres with the master account of my RDS Postgres instance, I get the following error
ERROR: must be owner of type character varying or type json
The owner is rdsadmin:
\dT+ varchar
List of data types
Schema | Name | Internal name | Size | Elements | Owner | Access privileges | Description
------------+-------------------+---------------+------+----------+----------+-------------------+-------------------------------------------------------------------
pg_catalog | character varying | varchar | var | | rdsadmin | | varchar(length), non-blank-padded string, variable storage length
Now I don't have rdsadmin password, is there any other way to run this query?
I don't think you can bootstrap your way to the full rdsadmin privileges.
However it seems that you can make yourself the owner of types:
ALTER TYPE json OWNER TO myowner;
And then you can create casts for that type to your heart's content.
My PostgreSQL (9.2) database contains two tables registrations and attributes with a foreign key constraint:
postgres=# \d+ registrations;
Table "public.registrations"
Column | Type | Modifiers | Storage | Stats target | Description
---------+-------+-----------+----------+--------------+-------------
name | text | not null | extended | |
parent | text | | extended | |
storage | bytea | | extended | |
Indexes:
"registrations_pkey" PRIMARY KEY, btree (name)
Referenced by:
TABLE "attributes" CONSTRAINT "attributes_cname_fkey" FOREIGN KEY (cname) REFERENCES registrations(name) ON DELETE CASCADE
Has OIDs: no
postgres=# \d+ attributes;
Table "public.attributes"
Column | Type | Modifiers | Storage | Stats target | Description
--------+-------+-----------+----------+--------------+-------------
cname | text | not null | extended | |
aname | text | not null | extended | |
tags | text | | extended | |
value | bytea | | extended | |
Indexes:
"attributes_pkey" PRIMARY KEY, btree (cname, aname)
Foreign-key constraints:
"attributes_cname_fkey" FOREIGN KEY (cname) REFERENCES registrations(name) ON DELETE CASCADE
Has OIDs: no
At some point I realised that some rows violated the foreign key constraint:
postgres=# SELECT COUNT(*) FROM attributes LEFT JOIN registrations ON attributes.cname=registrations.name WHERE registrations.name IS NULL;
count
-------
71
(1 row)
Could you help me understand how this corruption could happen?
A constraint marked as NOT VALID is the one case you might expect to see violations, but the NOT VALID clause would show up in the psql \d+ output. (I believe it's possible to manually update this flag in the catalog, but I hope for your sake that this isn't the issue...)
As far as I know, the only supported way of bypassing a foreign key check is to SET session_replication_role TO replica before modifying the data. This is there for the benefit of replication processes, operating under the assumption that the constraint has already been validated on the master - though this can certainly go wrong if your replicator is buggy or misconfigured.
It's also possible for a superuser to manually disable the constraint's underlying triggers (and it's often tempting for someone trying to speed up a bulk import). The following will tell you if the triggers are currently active (tgenabled should be 'O'):
SELECT *
FROM pg_trigger
WHERE tgname ~ '^RI_ConstraintTrigger'
AND tgrelid IN ('registrations'::regclass, 'attributes'::regclass)
I don't think there's any way of knowing whether this was temporarily changed in the past, though if you have statement logging enabled, you might find an ALTER TABLE ... DISABLE TRIGGER statement in there somewhere.
There is also at least one loophole in the foreign key enforcement, and of course, it's always possible that you've found a bug...
This can happen if the FK contraint was created with a NOT VALID clause (don't do this):
CREATE TABLE one
( one_id INTEGER NOT NULL PRIMARY KEY
);
CREATE TABLE two
( two_id INTEGER NOT NULL PRIMARY KEY
, one_id INTEGER NOT NULL
);
INSERT INTO one(one_id)
SELECT gs FROM generate_series(0,12,2) gs;
INSERT INTO two(two_id,one_id)
SELECT gs, gs FROM generate_series(0,12,3) gs;
ALTER TABLE two
ADD CONSTRAINT omg FOREIGN KEY (one_id) references one(one_id)
-- DEFERRABLE INITIALLY DEFERRED
NOT VALID
;
So I made some tables programatically and I want to verify it's structure is what I think it is.
>Rocko=# \c Rocko
Password for user Rocko:
psql (8.4.4, server 8.4.8)
You are now connected to database "Rocko".
Rocko=# \d
List of relations
Schema | Name | Type | Owner
--------+--------------+----------+-------
public | Email | table | Rocko
public | Email_id_seq | sequence | Rocko
public | Test | table | Rocko
public | Test_id_seq | sequence | Rocko
public | User | table | Rocko
public | User_id_seq | sequence | Rocko
(6 rows)
So, for example, I want to see the columns in Test.
Rocko=# \d Test
Did not find any relation named "Test".
Wait a minute?! Did not Test just show up under "List of Relations"? What's going on here?
PostgreSQL converts unquoted identifiers (such as table and column names) to lower case by default; the standard says that identifiers are supposed to be normalized to upper case but that's not important here. So, when you say this:
\d Test
PostgreSQL considers that the same as \d test. You probably have a table that was created with a quoted name:
create table "Test" ( ...
so that its name is case sensitive and must be quoted (with double quotes) every time it is referenced. So try quoting the name:
\d "Test"