Обсуждение: PITR performance costs

Since PITR has to enable archiving does this not increase the amount
of disk I/O required ?

Dave

Dave Cramer <pg@fastcrypt.com> 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

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,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

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 Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

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 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 Linnakangas
>   EnterpriseDB   http://www.enterprisedb.com

Dave, et al,

* Dave Cramer (pg@fastcrypt.com) 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, etc), they're probably in the system cache, so you're probably
not going out to disk to get those blocks anyway.  That might not be the
case on a slow-write system, but in those cases it seems at least
somewhat unlikely you'll be hit very hard by the occational 16MB copy
off the disk...

    Thanks,

        Stephen

> 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 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 Linnakangas
> >  EnterpriseDB   http://www.enterprisedb.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq

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:
http://developer.postgresql.org/pgdocs/postgres/populate.html#POPULATE-PITR

This isn't additional logging because of PITR, its just that we've had
to exclude PITR from some recent tuning operations. I'll be looking at
ways of making that optional in certain cases.

Overall, the cost of shipping WAL files away has been measured in large
scale tests by Mark Wong to be around 1% drop in measured peak
transaction throughput, tests about ~2 years ago now on 8.0. It's
possible that has increased as we have further tuned the server, but I'm
thinking its still fairly negligible overall.

Replication solutions currently weigh in significantly more than this
overhead, which is one reason to make me start thinking about log based
replication in future releases.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com

On 5/28/07, Dave Cramer <pg@fastcrypt.com> wrote:
> Since PITR has to enable archiving does this not increase the amount
> of disk I/O required ?

I've set up warm standbys on a few servers (some of them quite
busy!)...the additional load is virtually unmeasurable.  I usually
don't copy the files locally...I scp them off to some other server.
When archived, the WAL files are likely cached but there is some
overhead to copying them off however.

merlin