
Native Table Partitioning in PostgreSQL 10 - craigkerstiens
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63
======
comboy
duplicate:
[https://news.ycombinator.com/item?id=13128732](https://news.ycombinator.com/item?id=13128732)

also I think the link and title of this post don't match

------
jadbox
Anyone willing explain this to someone without context?

~~~
Zikes
Table partitions allow for automatic sharding of data across multiple tables,
while treating them as a single collection via a parent table.

~~~
agotterer
What is the benefit over PG schemas?

~~~
grzm
Table partitions are for managing data that would ideally belong in the same
table that for management reasons you'd like to split into multiple tables.
One application is for managing time series data where you only want to keep
the most recent data. For example, you want to save the most recent three
months. For implementation reasons, running

    
    
      DELETE FROM big_table
        WHERE some_timestamp < '2016-09-01'
    

is going to be painful. If you partition big_table by month, you can instead
issue 'DROP big_table_201609' when you're done with it. Much cleaner and
faster.

You could do this in previous versions, through convention and scripts. Having
it built into PostgreSQL should make this a lot easier.

Schemas are something else entirely.

------
jimktrains2
Did you mean to link to
[https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63)

This is a commit about synchronous replication not table partitioning.

~~~
craigkerstiens
Doh, yes, for some reason wrong link got posted. Bad copy and paste error.

~~~
dang
We replaced the link, but we also had to mark the story as a dupe (cf. comboy
upthread).

