Hi, 22.08.2008 17:51, Alex Ehrlich wrote: > Hello, > > (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, though... ... > 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 interesting. > Alex > > 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 sure myself. > 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 :-) Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de ------------------------------------------------------------------------- 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
