On Fri, 19 Nov 2010, Mikael Fridh wrote:

> The FUD stops here, this is pointless in the case of (where this
> discussion started) restore performance on a MySQL back-end.

In terms of restore performance, you're right. Better optimised queries
would speed things up, but probably not by much (see below: Bacula-dir is
the major factor on large restores)

> Pulling 5 million files out in one flat list is equally stupid to (or,
> rather in this case, a simplification) storing 5 million files in an
> unhashed directory structure.

I _have_ users who do that. (arrgh!)

> As soon as you see subqueries like these run against a MySQL server it
> is obvious it was not designed for MySQL and/or performance.

In both cases (mysql or postgres) the actual query is relatively fast for
1-2 million file backups, but then bacula-dir itself grinds on the results
for quite some time and it's memory-intensive while doing it.

I've pointed Kern at alternatives to red/black tables which will probably
speed that side up, but optimised queries are always a good idea.

> Frankly I don't know at this point how to make it better without
> restructuring the database and actually avoiding pulling out millions
> of millions of records at once.

If you can make a better mousetrap, Kern (and a lot of other people) will
probably thank you - even if it takes a major revision release to change
the database format.

FWIW, the EXPLAIN is just as ugly on postgres.

AB




------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to