[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Partitions (Was: Selective restore when files are pruned)
22.08.2008 17:51, Alex Ehrlich wrote:
> (as the original message sent was lost I resend this)
> Having a solid background in Oracle (incl. partitioning) and some
> experience with PostgreSQL (never used partitioning) I decided to make a
> short study.
Thanks. This is probably a helpful step to decide if partitioning is
the way to go.
My impression is that the "OldFiles" approach might be more useful in
the near time; implementing partitions is (perhaps) best left to the
local DB admin. Some hints in the documentation might be useful,
> And here goes the thing that I should have stared with ;-). What are the
> worst queries in question? what are the problems (problematic
> scenarios)? I cannot answer myself because my first setup is less than
> 10Mb so far... If we could assume that clientid is always known (at
> least in "problematic" queries) that would be of some help maybe (to add
> it to the "file" table again)...
There are, I believe, two bad cases that commonly happen.
1. A huge number of clients. This leads to a large number of file
entries and a table that would best be partitioned by client ID.
2. A single or a small number of huge file systems with loads of
files. In this case, splitting by file age might work best - as David
Boyes pointed out, it's a reasonable assumption that most of the time,
the current records are accessed, but the old ones might still be
> P.S. I've not found any database model picture in the Development
> documentation so I created one (reverse engineering a PostgreSQL setup
> and adding foreign keys manually to the picture). There seem to be many
> unused tables (marked yellow; at least, they are empty in my setup) and
> unused fields (especially "unused id fields"; foreign keys for them are
> drawn in red or just missing in the picture); the "red" table
> "mediatype" is just a total lie. Have I missed something?
No. Many of these tables and fields are created for future use; they
are needed for some projcets that are in very early stages. As the
mere existence of these tables at least doesn't cost much, they were
created when the developers decided the projects sound interesting and
a database upgrade was necessary anyway. The fields that are currently
unused take up some space, obviously. Some of them probably are
unnecessary; some others might seem unnecessary but are or were needed
for compatibility reasons between different database engines - I'm not
> P.P.S. I am afraid that it is the picture attachment that blocked my
> sending so I've removed it. Does anybody need the data model picture?
Would be nice in any case... but it might be best integrated into the
current developer docs. Ask Kern :-)
Sandstr. 6, 49080 Osnabrück
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.