James B. Byrne wrote:
> I have recently had to teach myself how to use git and the thought came to me
> that this tool might provide a fairly low setup cost way of passing pg_dumps
> over the network to our off site data store. Think Rsync, but on a file
> content basis; just the content diff gets transmitted.
>
> GiT works by compressing deltas of the contents of successive versions of file
> systems under repository control. It treats binary objects as just another
> object under control. The question is, are successive (compressed) dumps of
> an altered database sufficiently similar to make the deltas small enough to
> warrant this approach?
>
> Comments? (not my my sanity, please)
>
It probably depends on the number of changes in the database. For
example, a vacuum followed by an insert could result in records that
were previously at the start of the dump being somewhere else -like the
middle of the dump (i.e., a dead tuple is marked as available, then the
space is "used" for an insert). In such a case, you would end up with a
row that was unchanged, but in a different location in the file. Would
GIT then back that up? I would think so. So in essence you'd be
getting "at least a diff, but likely more" . Of course, I'm assuming
you are just dumping the data in a table using pg_dump....once you start
talking about a dumpall, you might find that smaller changes (i.e., give
a user a new privilege) causes stuff to be offset more.... Add
compression into the mix and I think you could find that there are
little/no similarities..
On the other hand, if you were only doing inserts into an optimized (no
dead tuples) table, I would think that you'd get a much better result.
Perhaps you would be better off using PITR in such cases?
--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
919-463-0999/877-258-8987
http://www.otg-nc.com