| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Greg Smith <greg(at)2ndquadrant(dot)com>, José Arthur Benetasso Villanova <jose(dot)arthur(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: directory archive format for pg_dump |
| Date: | 2010-12-16 19:29:02 |
| Message-ID: | 8305.1292527742@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 16.12.2010 20:33, Joachim Wieland wrote:
>> How exactly would you "just split the table in chunks of roughly the
>> same size" ?
> Check pg_class.relpages, and divide that evenly across the processes.
> That should be good enough.
Not even close ... relpages could be badly out of date. If you believe
it, you could fail to dump data that's in further-out pages. We'd need
to move pg_relpages() or some equivalent into core to make this
workable.
>> Which queries should pg_dump send to the backend?
> Hmm, I was thinking of "SELECT * FROM table WHERE ctid BETWEEN ? AND ?",
> but we don't support TidScans for ranges. Perhaps we could add that.
Yeah, that seems probably workable, given an up-to-date idea of the
possible block range.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-12-16 19:51:59 | Re: Extensions, patch v18 (merge against master, bitrot-only-fixes) |
| Previous Message | Alvaro Herrera | 2010-12-16 19:28:41 | Re: Extensions, patch v18 (merge against master, bitrot-only-fixes) |