Re: Pg_dump and bytaA - Mailing list pgsql-admin

From Ireneusz Pluta
Subject Re: Pg_dump and bytaA
Date
Msg-id 45F17AD9.1080507@wp.pl
Whole thread Raw
In response to Pg_dump and bytaA  ("Lukas" <lukas@fmf.vtu.lt>)
List pgsql-admin
Lukas napisał(a):
> Hello,
>
>  we have one table in database (db has over 200 tables), which has one
> byteA filed for storing user photos. We are making backup every night, but
> it is now too large because of photos. We do not need to make backup of
> photos every night, but the question is how to backup database without
> this field?
>  I tried to look at keys of pgdump, but found nothing...
>
> Now we are using it like this:
> pg_dump -f /home/backup/DB.sql -d -Fp -v DB
>
> thx
> Lukas
>
>
A different idea:

Why don't you move your photos table to a dedicated schema? Then you can
dump only main schema, not including the photos schema, with the -n
option to pg_dump. So, assuming that 'public' is the schema where all
your other tables exist, your command would look like:

pg_dump -n public -f /home/backup/DB.sql -d -Fp -v DB

If you then change your mind and find that you need photos dump too, but
possibly on a schedule different from the rest, you may be dumping only
photos schema with something like:

pg_dump -n photos -f /home/backup/photos.sql -d -Fp -v DB

however you might want a different output format (compressed?) in this case.

Of course, this change would require you to make your application know
where the photos table is. But most probably this can be easily done by
executing something like "SET search_path TO photos, public", just after
each connection to your database.

Irek.


pgsql-admin by date:

Previous
From: "Milen A. Radev"
Date:
Subject: Re: Pg_dump and bytaA
Next
From: "Glen W. Mabey"
Date:
Subject: problem upgrading from 8.1.6 to 8.1.8 --- relation does not exist