PostgreSQL 10 introduced the native table partitioning which is better than old/manual table partitioning.

Before, we had to manage table partitioning by specifying Trigger and Check constraint.
Now, in the new version, it handles automatically and reduces the work of DBA.

Check the below example of Native Table Partitioning:

Create a table and define the Partition column:

CREATE TABLE tbl_employee 
(
     empid int GENERATED BY DEFAULT AS IDENTITY,
     empname character varying,
     joiningdate timestamp without time zone
) PARTITION BY RANGE (joiningdate);

Create three sample partitions on joiningdate:

CREATE TABLE tbl_employee_history_201701
PARTITION OF tbl_employee
FOR VALUES FROM ('2017-01-01 00:00:00') TO ('2017-01-31 23:59:59');

CREATE TABLE tbl_employee_history_201702
PARTITION OF tbl_employee
FOR VALUES FROM ('2017-02-01 00:00:00') TO ('2017-02-28 23:59:59');

CREATE TABLE tbl_employee_history_201703
PARTITION OF tbl_employee
FOR VALUES FROM ('2017-03-01 00:00:00') TO ('2017-03-31 23:59:59');

Insert few sample records:

INSERT INTO tbl_employee
VALUES (1,'Anvesh','2017-01-08'),
(2,'Roy','2017-02-10'),(3,'Jenny','2017-03-12');

Check the main table, you can get all records:

select *From tbl_employee;

Check individual table partition for specific range data:

select *From tbl_employee_history_201701;
select *From tbl_employee_history_201702;
select *From tbl_employee_history_201703;

Important Notice/Change in PostgreSQL 10.

Previously, xlog referred to as transaction log including their directories and functions. Now xlog changed to wal.
If you are starting to use PostgreSQL 10, you have to change all old admin scripts and functions from xlog to wal.

Also, PostgreSQL 10 changed location word to lsn in few function names.

Please check the changes:

Directories: (9.6 to 10)

pg_xlog –> pg_wal
pg_clog –> pg_xact

Functions:

pg_current_xlog_flush_location –> pg_current_wal_flush_lsn
pg_current_xlog_insert_location –> pg_current_wal_insert_lsn
pg_current_xlog_location –> pg_current_wal_lsn
pg_is_xlog_replay_paused –> pg_is_wal_replay_paused
pg_last_xlog_receive_location –> pg_last_wal_receive_lsn
pg_last_xlog_replay_location –> pg_last_wal_replay_lsn
pg_switch_xlog –> pg_switch_wal
pg_xlog_location_diff –> pg_wal_lsn_diff
pg_xlog_replay_pause –> pg_wal_replay_pause
pg_xlog_replay_resume –> pg_wal_replay_resume
pg_xlogfile_name –> pg_walfile_name
pg_xlogfile_name_offset –> pg_walfile_name_offset

Reference taken from pgwiki:

PostgreSQL 10 introduced many useful features that we can use in day to day work.

Now, we can trace the status of the running transaction in PostgreSQL 10. If we have transaction IDs of our sessions and suddenly database crashed or shutdown, we can check the status of those transactions.

We can check the status like Committed, In Progress, Rollback or Aborted. This facility will help a lot for taking a necessary decision on crashed transactions.

PostgreSQL 10 introduced two functions:

txid_current() – will return the current transaction id of a session
txid_status() – will return the status of transaction

Please check the below sample:

Create a sample table:

CREATE TABLE tbl_stud
(Rno INT, Name Character Varying);

Open a transaction, and insert a record:

BEGIN TRANSACTION;

INSERT INTO tbl_stud
VALUES (1,'Anvesh');

Check the current transaction id:

SELECT *FROM txid_current();

txid_current
------------
    587

Check the status of above transaction id:
It is showing “in progress” because I didn’t commit the transaction yet.

SELECT txid_status(BIGINT '587');

txid_status
-----------
in progress

Now, execute the COMMIT:

COMMIT TRANSACTION;

Now, check the status again:

SELECT txid_status(BIGINT '587');

txid_status
-----------
committed

You can also return transaction id, with the insert statement: (Using RETURNING)

SELECT txid_status(BIGINT '587');

txid_status
-----------
committed

PostgreSQL 10 introduced the concept of XML Table where we can store full XML Document.
We can retrieve the XML Document in a tabular format.

In the ETL process, we can extract XML files and directly stores into a relational table format. Later, we can apply any filters on it.

Check the below simple demonstration on this:

Create a sample XML Table:

CREATE TABLE tbl_Students AS SELECT xml
$$              
<students>
 <class id="A">
  <name>Anvesh</name>
  <subjects>
   <subject name="English"></subject>
   <subject name="Computer"></subject>
  </subjects>
  </class>
 </students>
 $$ AS Students;

Get XML data into Tabular format:

SELECT xmltable.*
  FROM tbl_Students,
       XMLTABLE ('/students/class/subjects/subject' PASSING Students
                 COLUMNS
                    id FOR ORDINALITY,
                    Student_Name text PATH '../../name' NOT NULL
                 	,Subject_Name text PATH '@name'
                );

Result:

id   |  student_name   |   subject_name
______________________________________________
 1    |  Anvesh         |   English
 2    |  Anvesh         |   Computer

PostgreSQL 10 IDENTITY Column is an excellent feature of this version. Since the beginning of Microsoft SQL Server, IDENTITY Column is available with it.

SQL Server 2012 introduced Sequence Object, and since beginning SERIAL/BIGSERIAL (Sequence Object) are available in PostgreSQL.

The new IDENTITY Type Column is used to generate an automatic number.
Now, we have this great feature, and creating an auto-increment column is also very simple.

Why is IDENTITY good over SERIAL/BIGSERIAL (Sequence Object)?

Sequence Object requires additional permission
Managing the Sequence Object is difficult while migrating table structure

Check the below example:

Create a sample table with IDENTITY column:

CREATE TABLE tbl_test (
    id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    name character varying
);

Insert few records:

INSERT INTO tbl_test (name) 
VALUES ('abc'), ('xyz'), ('pqr');

Check the result:

SELECT *FROM tbl_test;

id    |    name 
-------------------
1      |     abc
2      |     xyz
3      |     pqr

The most waiting version, PostgreSQL 10 launched on 2017-10-05.
PostgreSQL 9.6 came with parallel query processing, on which PostgreSQL 10 Improved query parallelism operations.

PostgreSQL 9.6: Powerful Parallel Query Processing – Full Performance Test

Use this link, for download and use PostgreSQL 10

Few highlighted features of PostgreSQL 10.

• Logical replication using publish/subscribe
• Declarative table partitioning
• Improved query parallelism
• Significant general performance improvements
• Stronger password authentication based on SCRAM-SHA-256
• Improved monitoring and control

In coming days, I will explore the new features of PostgreSQL 10.