Re: Patch: dumping tables data in multiple chunks in pg_dump - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Patch: dumping tables data in multiple chunks in pg_dump
Date
Msg-id CAMT0RQROPMSPwfxAUCm1gZs9cUr7FmvwX+eO6Wzq_wWdd6eEAQ@mail.gmail.com
Whole thread Raw
In response to Re: Patch: dumping tables data in multiple chunks in pg_dump  (Hannu Krosing <hannuk@google.com>)
Responses Re: Patch: dumping tables data in multiple chunks in pg_dump
List pgsql-hackers
Please find the latest patch attached which incorporates the feedback received.

* changed flag name to --max-table-segment-pages
* added check for amname = "heap"
* switched to using of
pg_relation_size(c.oid)/current_setting('block_size')::int when
--max-table-segment-pages is set
* added option_parse_uint32(...) to be used for full range of pages numbers
* The COPY SELECTs now use <= , BETWEEN or >= depending on the segment position

* added documentation

* TESTS:
  * added simple chunked dump and restore test
  * added a WARNING with count and table data hash to source and
chunked restore database

I left in the boolean to indicate if this is a full table or chunk
(was named chunking, nor is_segment)

An a lternative would be to use an expression like (td->startPage != 0
|| td->endPage != InvalidBlockNumber) whenever td->is_segment is
needed

If you insist on not having a separate structure member we could turn
this into something like this

#define is_segment(td) ((td->startPage != 0 || td->endPage !=
InvalidBlockNumber))

and then use is_segment(td) instead of td->is_segment where needed.

Attachment

pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Add WALRCV_CONNECTING state to walreceiver
Next
From: Peter Eisentraut
Date:
Subject: Re: Remove more leftovers of AIX support