Skip site navigation (1) Skip section navigation (2)

Re: Proposed patch: synchronized_scanning GUC variable

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Kris Jurka <books(at)ejurka(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgreSQL(dot)org
Subject: Re: Proposed patch: synchronized_scanning GUC variable
Date: 2008-01-29 11:26:44
Message-ID: 479F0D74.5080409@kaltenbrunner.cc (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Gregory Stark wrote:
> "Kris Jurka" <books(at)ejurka(dot)com> writes:
> 
>> On Mon, 28 Jan 2008, Jeff Davis wrote:
>>
>>> I think that pg_dump is a reasonable use case for synchoronized scans
>>> when the table has not been clustered. It could potentially make pg_dump
>>> have much less of a performance impact when run against an active
>>> system.
>> One of the advantages I see with maintaining table dump order is that rsyncing
>> backups to remote locations will work better.
> 
> I can't see what scenario you're talking about here. pg_dump your live
> database, restore it elsewhere, then shut down the production database and run
> rsync from the live database to the restored one? Why not just run rsync for
> the initial transfer?

take a dump (maybe in plaintext format) save it to disk and use rsync to 
copy it elsewhere. the more "similiar" the dumps the more efficient 
rsync can copy the data over.


Stefan

In response to

pgsql-hackers by date

Next:From: Gevik BabakhaniDate: 2008-01-29 11:28:15
Subject: Re: How to use VB6 for store image to postgresql?
Previous:From: Gregory StarkDate: 2008-01-29 11:04:48
Subject: Re: Proposed patch: synchronized_scanning GUC variable

pgsql-patches by date

Next:From: Euler Taveira de OliveiraDate: 2008-01-29 13:31:01
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Gregory StarkDate: 2008-01-29 11:04:48
Subject: Re: Proposed patch: synchronized_scanning GUC variable

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group