| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, amul sul <sulamul(at)gmail(dot)com> |
| Subject: | Re: Hash Functions |
| Date: | 2017-05-12 20:12:22 |
| Message-ID: | 1f2742d5-ef44-393a-dbb1-ed992cd307cc@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 5/12/17 14:23, Robert Haas wrote:
> One alternative would be to change the way that we dump and restore
> the data. Instead of dumping the data with the individual partitions,
> dump it all out for the parent and let tuple routing sort it out at
> restore time.
I think this could be a pg_dump option. One way it dumps out the
partitions, and another way it recomputes the partitions. I think that
could be well within pg_dump's mandate.
(cough ... logical replication ... cough)
> Of course, this isn't very satisfying because now
> dump-and-restore hasn't really preserved the state of the database;
That depends no whether you consider the partitions to be a user-visible
or an internal detail. The current approach is sort of in the middle,
so it makes sense to allow the user to interpret it either way depending
on need.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-05-12 20:36:30 | Re: WITH clause in CREATE STATISTICS |
| Previous Message | Alvaro Herrera | 2017-05-12 19:52:50 | Tab-completing DROP STATISTICS |