Since PITR has to enable archiving does this not increase the amount
of disk I/O required ?
Dave
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Dave Cramer <[EMAIL PROTECTED]> wrote:
> Since PITR has to enable archiving does this not increase the amount
> of disk I/O required ?
It does increase the required amount of I/O.
--
Bill Moran
http://www.potentialtech.com
---(end of broadcast)
am Mon, dem 28.05.2007, um 8:45:38 -0400 mailte Dave Cramer folgendes:
> Since PITR has to enable archiving does this not increase the amount
> of disk I/O required ?
Yes. But you can use a different hard drive for this log.
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D
Dave Cramer wrote:
Since PITR has to enable archiving does this not increase the amount of
disk I/O required ?
There's no difference in normal DML operations, but some bulk operations
like CREATE INDEX that don't otherwise generate WAL, need to be WAL
logged when archiving is enabled.
--
Heikki,
Don't the archived logs have to be copied as well as the regular WAL
logs get recycled ?
Dave
On 28-May-07, at 12:31 PM, Heikki Linnakangas wrote:
Dave Cramer wrote:
Since PITR has to enable archiving does this not increase the
amount of disk I/O required ?
There's no difference
Dave, et al,
* Dave Cramer ([EMAIL PROTECTED]) wrote:
> Don't the archived logs have to be copied as well as the regular WAL
> logs get recycled ?
Yes, but I'd expect at the point they're being copied off to some other
store (probably a seperate disk, or even over the network to another
system,
On Mon, 2007-05-28 at 08:45 -0400, Dave Cramer wrote:
> Since PITR has to enable archiving does this not increase the amount
> of disk I/O required ?
As Heikki says, some operations need logging when PITR is on; these are
now documented in the performance tips section of the latest dev docs:
ht
Please let us know if there is something we should change in the
PostgreSQL source code.
---
Peter T. Breuer wrote:
> "Also sprach Tom Lane:"
> > > It may still be useful. The kernel won't necessarily send data as you
> > >
On Sun, 27 May 2007 19:34:30 +0200, PFC <[EMAIL PROTECTED]> wrote:
On Sun, 27 May 2007 17:53:38 +0200, Jim C. Nasby <[EMAIL PROTECTED]>
wrote:
On Tue, May 22, 2007 at 09:29:00AM +0200, PFC wrote:
This does not run a complete sort on the table. It would be about as
fast as your seq
