| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 22:13:52 |
| Message-ID: | 20170512221352.u4uprotlvnbznsxw@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> 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.
I was thinking the same, but enable that option automatically for hash
partitioning. Each partition is still dumped separately, but instead of
referencing the specific partition in the TABLE DATA object, reference
the parent table. This way, the restore can still be parallelized, but
tuple routing is executed for each tuple.
> (cough ... logical replication ... cough)
I think for logical replication the tuple should appear as being in the
parent table, not the partition. No?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-05-12 22:38:55 | Re: Hash Functions |
| Previous Message | Alvaro Herrera | 2017-05-12 22:10:10 | Re: WITH clause in CREATE STATISTICS |