How to unlock users with expired password in postgreSQL

select now()+'90 days' as expiry;
 expiry
-------------------------------
 2019-08-07 10:07:01.172082+02
\gset
alter user jim valid until :'expiry';
ALTER ROLE

The command "\gset" sends the current query buffer to the server and stores the query's output into a psql variable.

After the change, use \du to verify that the password has the correct expiry time:

mydb01=# \du
                                            List of roles
     Role name     |                         Attributes                         |      Member of
-------------------+------------------------------------------------------------+---------------------
 postgres          | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
                   | Password valid until 2019-01-16 00:00:00+01                |
 superuser         | Superuser                                                 +| {}
                   | Password valid until 2019-08-04 00:00:00+02                |
 jim               | Password valid until 2019-08-07 10:07:03.237862+02         | {}

Use the "\list" command to list databases and access privileges, if desirable:

mydb01=# \list
                                    List of databases
   Name    |  Owner   | Encoding |  Collate   |   Ctype    |      Access privileges
-----------+----------+----------+------------+------------+------------------------------
 postgres  | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 template0 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres                 +
           |          |          |            |            | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres                 +
           |          |          |            |            | postgres=CTc/postgres
 mydb01    | jim      | UTF8     | en_US.utf8 | en_US.utf8 | =Tc/jim                     +
           |          |          |            |            | jim=CTc/jim                 +

To give the user a new password, use this syntax:

alter role jim password 'mynewpassword';

Consult the documentation for more information

How to explain a query in PostgreSQL

If you are using partitioned tables, make sure you have enabled partition pruning:

SET enable_partition_pruning to on;

The explain statement is simple enough:

explain select * from documents where dokumenttype='SUBPOENA';

                            QUERY PLAN
---------------------------------------------------------------------
 Append  (cost=0.00..1.02 rows=1 width=774)
   ->  Seq Scan on P_SUBPOENA  (cost=0.00..1.01 rows=1 width=774)
         Filter: ((documenttype)::text = 'SUBPOENA'::text)
(3 rows)

Since this is the LIST-partitioned table outlined in this post, I know the optimizer picked the correct partition for my predicate.

For the LIST-range subpartitioned table outlined in this post, I get the following query plan:

explain select * from orders where country_code='se' and order_total between 4000 and 4999;
                                                           QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
 Append  (cost=0.00..28.21 rows=1 width=50)
   ->  Seq Scan on large_orders_se  (cost=0.00..28.20 rows=1 width=50)
         Filter: ((order_total >= '4000'::numeric) AND (order_total <= '4999'::numeric) AND ((country_code)::text = 'se'::text))
(3 rows)

Regarding parallelism, the documentation tells you to watch for the terms Gather or Gather Merge Node in the query plan:
An example:

"Subquery Scan on andre  (cost=1000.00..10024950.78 rows=294885 width=84)"
"  ->  Gather  (cost=1000.00..10013892.60 rows=294885 width=64)"
"        Workers Planned: 2"
"        ->  ProjectSet  (cost=0.00..9983404.10 rows=29488500 width=64)"
"              ->  ProjectSet  (cost=0.00..9830063.90 rows=12286900 width=128)"

How to create a LIST partitioned table in PostgreSQL

Create the table:

CREATE TABLE DOCUMENTS(
  DOC_ID                      INTEGER  NOT NULL,
  LEGAL_ENTITY                INTEGER       NULL,
  CREATED_DT                  DATE      NOT NULL,
  REGION                      VARCHAR(30)   NULL,
  DOCUMENTTYPE                VARCHAR(100)  NULL,
  DOCUMENTNAME                VARCHAR(1000) NULL
)
PARTITION BY LIST (DOCUMENTTYPE);

Create a couple of partitions, including a default partition:

CREATE TABLE P_SUBPOENAS PARTITION OF  DOCUMENTS FOR VALUES IN  ('SUBPOENA');
CREATE TABLE P_AFFIDAVITS PARTITION OF DOCUMENTS FOR VALUES IN  ('AFFIDAVIT');
CREATE TABLE P_MEMORANDOMS PARTITION OF DOCUMENTS FOR VALUES IN ('MEMORANDOM');
CREATE TABLE P_DEFAULT PARTITION OF DOCUMENTS DEFAULT;

To add a primary key to a partitioned table, read this post

If your LIST-partitioned table would benefit from sub-partitioning, read this post

What exactly is meant by "global statistics" on a partitioned table?

From the whitepaper "Understanding Optimizer Statistics":

"When dealing with partitioned tables the Optimizer relies on both the statistics for the entire table
(global statistics) as well as the statistics for the individual partitions (partition statistics) to select a
good execution plan for a SQL statement. If the query needs to access only a single partition, the
Optimizer uses only the statistics of the accessed partition. If the query access more than one partition,
it uses a combination of global and partition statistics."

How to manuall purge your unified auditing audit trail

This is how I purged my unified audit trail on an Oracle 12.2 instance. The procedure has also been tested in a 19c instance.

First, check the LAST_ARCHIVE_TS:

SELECT * FROM DBA_AUDIT_MGMT_LAST_ARCH_TS;

If you want to keep some of your audit records, set a timestamp before which all records should be purged. In this particular example, I want to preserve only the last 30 days worth of audit data. The rest can be purged:

BEGIN
  DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP (
    AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
    LAST_ARCHIVE_TIME => SYSTIMESTAMP-30);
END;
/

Purge the audit trail, up until the LAST_ARCHIVE_TIMESTAMP:

BEGIN
  DBMS_AUDIT_MGMT.clean_audit_trail(
   audit_trail_type        => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
   use_last_arch_timestamp => TRUE);
END;
/

If you simply want to purge all records, run the same procedure but without the "use_last_arch_timestamp" directive:

BEGIN
  DBMS_AUDIT_MGMT.clean_audit_trail(
   audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
   use_last_arch_timestamp => FALSE);
   );
END;
/

The dbms_audit_mgmt is documented here

How to create a unique constraint with an existing index (the USING-clause)

Create the index:

CREATE UNIQUE INDEX MYTABLE_IDX1 ON MYTABLE
(ID,CATEGORY)
LOCAL
TABLESPACE USERS
ONLINE;

Create a unique constraint:

ALTER TABLE MYTABLE ADD (
CONSTRAINT UK_MYTABLE
UNIQUE (ID,CATEGORY)
USING INDEX MYTABLE_IDX1
);

For a primary key constraint the syntax is similar.
In this example, an index named MYTABLE_PK will be automatically created on the fly:

ALTER TABLE MYTABLE ADD (
CONSTRAINT MYTABLE_PK
PRIMARY KEY (ID)
USING INDEX);

A workaround for ORA-54033: column to be modified is used in a virtual column expression

Applicable for Oracle 12.1.0.2.

My customer reports that an attempt to execute a simple DDL statement failed:

ALTER TABLE mytable
MODIFY (COL2 DATE );

The error thrown was: ORA-54033: column to be modified is used in a virtual column expression.

Quite correctly, a look at the table revealed a virtual column:

set lines 200
col owner format a15
col table_name format a30
col column_name format a30
col data_default format a60

select owner,table_name,column_name, data_Default
from dba_tab_cols
where table_name='MYTABLE'
and hidden_column='YES';

Output:

OWNER           TABLE_NAME      COLUMN_NAME                    DATA_DEFAULT                                                                    
--------------- --------------- ------------------------------ -----------------------------------------------
SCOTT           MYTABLE         SYS_STSC13O20ML6_5OD25YOF16STK SYS_OP_COMBINED_HASH("COL1","COL2","COL3","COL4")             
1 row selected.

You can also query the DBA_STAT_EXTENSION to get similar information:

set lines 200
col extension_name format a30
col extension format a50

SELECT EXTENSION_NAME, EXTENSION,creator,droppable
FROM DBA_STAT_EXTENSIONS
WHERE TABLE_NAME='MYTABLE';

Output:

EXTENSION_NAME                 EXTENSION                      CREATOR DROPPABLE
------------------------------ ------------------------------ ------- ---------
SYS_STSC13O20ML6_5OD25YOF16STK ("COL1","COL2","COL3","COL4")  SYSTEM  YES      
1 row selected.

So in order to modify the existing column, the extended statistics will have to be dropped and recreated:

set lines 200
set serveroutput on
set timing on

BEGIN
  dbms_stats.drop_extended_stats('SCOTT', 'MYTABLE', '(COL1,COL2,COL3,COL4)');
END;
/

ALTER TABLE mytable
MODIFY (COL2 DATE );

select dbms_stats.create_extended_stats('SCOTT', 'MYTABLE', '(COL1,COL2,COL3,COL4)') 
from dual;