Not necessarily. Depending on how pg_dump works, it could be that
small changes to the database are resulting in unnecessarily large
changes to the dump. Make sure you are using the uncompressed format
because most compression algorithms defeat the delta-transfer
algorithm almost completely.
On 9/24/07, Fabian Cenedese [EMAIL PROTECTED] wrote:
I was wondering if it would be possible to add a switch (probably coupled
to -v(+) ) that would report the number of matched blocks per file. Maybe
even with the offset of the block.
Rsync already lists all matched blocks by their offsets
At 07:51 24.09.2007 -0400, Matt McCutchen wrote:
On 9/24/07, Fabian Cenedese [EMAIL PROTECTED] wrote:
I was wondering if it would be possible to add a switch (probably coupled
to -v(+) ) that would report the number of matched blocks per file. Maybe
even with the offset of the block.
Rsync
is actually smaller some days than the destination, will
that affect delta copies? This is because the db is a mail cache and
items expire each night and get purged from the database, then vacuumed.
So, the size will relatively stay the same, but will fluctuate sometimes
larger, sometimes smaller
On 9/23/07, Robert Fitzpatrick [EMAIL PROTECTED] wrote:
Doing some more testing this morning, maybe what you suggested about the
pgsql backup is what is happening. I took a closer look and realize that
my sql backup is actually smaller some days than the destination, will
that affect delta
On 9/23/07, Robert Fitzpatrick [EMAIL PROTECTED] wrote:
On Sun, 2007-09-23 at 00:56 -0400, Matt McCutchen wrote:
Either the delta transfer algorithm is not being used due to a
misconfiguration, or the pgsql backups are changing in a perverse way
that prevents it from matching any data.
On Sun, 2007-09-23 at 12:09 -0400, Matt McCutchen wrote:
On 9/23/07, Robert Fitzpatrick [EMAIL PROTECTED] wrote:
On Sun, 2007-09-23 at 00:56 -0400, Matt McCutchen wrote:
Either the delta transfer algorithm is not being used due to a
misconfiguration, or the pgsql backups are changing in a
On 9/23/07, WebTent [EMAIL PROTECTED] wrote:
Well, I am getting matched data, but it just doesn't seem to be matching
very much considering the small change in file size. I tested one dump
after another rsyncing in between dumps and got very little matched
data :(
mx1# pg_dump -Fc -Upgsql
On Sun, 2007-09-23 at 17:46 -0400, Matt McCutchen wrote:
On 9/23/07, WebTent [EMAIL PROTECTED] wrote:
Not necessarily. Depending on how pg_dump works, it could be that
small changes to the database are resulting in unnecessarily large
changes to the dump. Make sure you are using the
servers. So, I'd like this to happen for me,
thanks for any help...Also, does the match data bytes show the amount
matched when making delta copies, I assume? This seems to be the case as
the above shows zero and I see almost the same amount of byes here in my
Windows transfer.
--
Robert
reduction delta
transfers would achieve.
Also, does the match data bytes show the amount
matched when making delta copies, I assume?
Yes. More precisely, it shows the amount that rsync found to be
matched. Rsync's goal is to match as much data as convenient, not to
give you an exact measure of how
On Sat, 2007-09-22 at 20:00 -0400, Matt McCutchen wrote:
On 9/22/07, Robert Fitzpatrick [EMAIL PROTECTED] wrote:
Delta transfers reduce network traffic between the sending and
receiving rsync processes at the cost of some extra CPU time and disk
I/O (e.g., the receiver has to read the old
On 9/22/07, Robert Fitzpatrick [EMAIL PROTECTED] wrote:
Are you saying that rsync knows
the difference and will enable/disable delta transfers depending on
whether local or not?
Yes.
However, again, I get the same result doing remote
transfers.
Either the delta transfer algorithm is not
13 matches
Mail list logo
