SlideShare a Scribd company logo
PostgreSQL: present
and near future
1/Less obvious than it
should
● SQL is much more than a language to acces your
database: SQL allows you to forget about which is the most
efficient way to obtain the data you need in a large dataset.
1.1/SQL sucks! Let's use semething new!
● We usually compare PostgreSQL to Oracle as if that was
the opponent to beat, but try to CREATE TABLE inside a
transaction in Oracle...
1.2/Transactions don't look the same everywhere
● Locking
● Indexes
● Storage optimized for lots of datatypes
● ...
1.3/And much, much more
● EnterpriseDB – Robert Haas – Helped Amazon build RDS
● 2ndQuadrant – Simon Riggs – Developers around the
world working on key core features
● Citus – Andres Freund – CitusDB: clustered PostgreSQL
● PostgreSQL Professional – Oleg Bartunov – Full Text
Search
● Nippon Telegraph & Telephone...
● Tom Lane
● ...
1.4/...including an encredible (and profitable) community
2/What's new in 9.6
● A lot of work has gone in recent versions to make
PostgreSQL highly scalable (vertically) by optimizing
locked codeblocks.
● Multiple standby servers
● postgres_fdw
2.1/Scalability
2.1.1/Multiple standby servers – replication
● Previously only one processor/core could be used per
query. Now it can be used in sequential scans, joins and
aggregates.
2.2/Parallel queries
● CUBE, ROLLUP, GROUPING SETS
● WITH & WITH RECURSIVE
● MATERIALIZED VIEWS
● Full text search
● Row-level security
● JSONB
2.3/SQL completeness
● Checksums
● WAL
● synchronous_comit = on/of
2.4/Durability
RAM
2.4.1/Durability - Architecture
Durable
storage
Postgres
Shared
memory
Client
Filesystem
Cache
Structured data
WAL: Write Ahead Log
3/What's the community
working on for v10?
● Even more scalability work (large number of cores and
clients required for testing)
● Quorum commit
● Logical replication – pglogical in core
● Pushing more stuf into postgres_fdw
3.1/Scalability
3.1.1/Quorum commit
● AUTONOMOUS TRANSACTIONS
3.2/SQL completeness
● CREATE INDEX – sorting
● Bitmap scans
● Index scans
● Asynchronous execution
3.3/Parallel queries
● Amcheck – tool to check the correctness of data
● pg_heal
3.4/Durability
● Sorting improvements
● Constant evaluation improvements
● Fetching several tuples “at once”
3.5/Performance
4/What should Tryton be
using but isn't and what
can we learn?
● Unaccent
● Full text search
● Trigram indexes for LIKE searches
4.1/Texts and searching
● How do we create indexes which are not re-done on
update?
4.2/Better indexes
● PostgreSQL has lots of tools to try to understand what's
going on.
4.3/To learn: tools to know what's going on
http://www.NaN-tic.com
Albert Cervera i Areny
albert@nan-tic.com
@albertnan
linkedin.com/in/albertca
PostgreSQL: present and near future

More Related Content

PostgreSQL: present and near future