From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 9.3: load path to mitigate load penalty for checksums |
Date: | 2012-06-12 22:03:37 |
Message-ID: | 1339538617.12295.51.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2012-06-12 at 17:53 -0400, Bruce Momjian wrote:
> Well, truncating tables that were empty on the load would certainly be
> a easy to do --- not sure if that helps us, though.
This goes back to the single-loader-into-an-empty-table case, which I'd
like to get away from. I think we already have some reasonable proposals
on the table for optimizing that case.
Ultimately, that pushes us toward partitioning with the same granularity
as the data load. We can try to open that discussion up, but I think
it's a bad idea to tie the data load granularity to the partitioning
granularity, unless we have a way to coalesce them later without
rewriting. It's too bad filesystems don't allow us to just reallocate
some blocks from one file to another. [ OK, I guess I just opened this
discussion myself ;) ]
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-06-12 22:13:13 | Re: 9.2 final |
Previous Message | Tom Lane | 2012-06-12 22:02:48 | Re: 9.3: load path to mitigate load penalty for checksums |