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 <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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 5: don't forget to increase your free space map settings

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGWzF7rzgMPqB3kigRAnBJAKCOXF9MsSpU64DCpoJzRE QE+SaEuQCeIqaN
dl3JKBpjRY/s2g31/vaj1cw=
=F8bG
-----END PGP SIGNATURE-----

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/pgdo...#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



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster