Hi, baculamaniacs ;)
If you remember, I held a series of tests on the speed Bacula.
I compared the two DB scheme: canonical vs alternative (to the
disclosure LStat in several columns).
So good news: canonical DB scheme won, was faster. Details are not yet writing.
However (and this is "bad" news
On Tuesday 14 October 2008 10:06:22 Yuri Timofeev wrote:
> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> > On Tuesday 14 October 2008 09:39:27 John Huttley wrote:
> >> So the modified version is actually a bit faster?
> >
> > That is what I understood too, but I wanted to get a confirmation.
> >
>
2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> On Tuesday 14 October 2008 10:06:22 Yuri Timofeev wrote:
>> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
>> > On Tuesday 14 October 2008 09:39:27 John Huttley wrote:
>> >> So the modified version is actually a bit faster?
>> >
>> > That is what I under
On Tuesday 14 October 2008 11:12:17 Yuri Timofeev wrote:
> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> > On Tuesday 14 October 2008 10:42:22 Yuri Timofeev wrote:
> >> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> >> > On Tuesday 14 October 2008 10:06:22 Yuri Timofeev wrote:
> >> >> 2008/10/14 K
Hello,
Could you summarize the difference in your schemas.
>From what I am seeing it looks like your first test that ran 39 hours is a
standard Bacula File table more or less, and the second test NEW DB that ran
35 hours is a standard Bacula File table with additional fields and produces
a sma
2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> On Tuesday 14 October 2008 10:42:22 Yuri Timofeev wrote:
>> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
>> > On Tuesday 14 October 2008 10:06:22 Yuri Timofeev wrote:
>> >> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
>> >> > On Tuesday 14 October 2008
On Tuesday 14 October 2008 10:42:22 Yuri Timofeev wrote:
> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> > On Tuesday 14 October 2008 10:06:22 Yuri Timofeev wrote:
> >> 2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> >> > On Tuesday 14 October 2008 09:39:27 John Huttley wrote:
> >> >> So the modifi
2008/10/14 Kern Sibbald <[EMAIL PROTECTED]>:
> On Tuesday 14 October 2008 09:39:27 John Huttley wrote:
>> So the modified version is actually a bit faster?
>
> That is what I understood too, but I wanted to get a confirmation.
>
> If it is indeed the case that the new case runs faster, it is indeed
2008/10/14 John Huttley <[EMAIL PROTECTED]>:
> So the modified version is actually a bit faster?
>
Well, yes.
> Thats odd.
So that MySQL slow with fields of type BLOB, imho.
In an alternative scheme appear new fields : size, ctime, mtime.
I therefore reduced length the value that is inserted in
On Tuesday 14 October 2008 09:39:27 John Huttley wrote:
> So the modified version is actually a bit faster?
That is what I understood too, but I wanted to get a confirmation.
If it is indeed the case that the new case runs faster, it is indeed odd, and
I would say the tester has fallen into a ve
So the modified version is actually a bit faster?
Thats odd.
are you running 64Bit?
Whats your Ram?
Version of Mysql?
I'll run it on my system also.
Regards,
john
Yuri Timofeev wrote:
Hi
2008/10/7 John Huttley <[EMAIL PROTECTED]>:
Hi
My first test are complete.
To aid in getting all
Hi
2008/10/7 John Huttley <[EMAIL PROTECTED]>:
> Hi
> My first test are complete.
> To aid in getting all the questions/answers and results in one place, I've
> made a wiki entry.
>
> http://wiki.bacula.org/doku.php?id=wiki:playground
>
My first test are complete. ;)
Summary:
MySQL, ProLiant DL
Sorry.
I was wrong.
I am now looking into the source code bacula.
Working with postgresql is using:
'COPY batch FROM STDIN'
(not INSERT ;)
I am now prepared and launched a test for MySQL. I look forward to
when it will end. ;)
2008/10/8 Yuri Timofeev <[EMAIL PROTECTED]>:
> Good work!
> But...
> I
Yuri Timofeev wrote:
> Good work!
> But...
> I think the test is not quite correct. ;)
> I am talking about the command "COPY" in PostgreSQL.
>
> In other words, I think that COPY and INSERT performed differently.
> "COPY" must be implemented faster than individual "INSERT" into real Bacula
> Job
Does anyone think we need ctime?
Else I can run the tests without it.
--John
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win gr
On Oct 8, 2008, at 11:12 AM, Yuri Timofeev wrote:
> Good work!
> But...
> I think the test is not quite correct. ;)
> I am talking about the command "COPY" in PostgreSQL.
>
> In other words, I think that COPY and INSERT performed differently.
> "COPY" must be implemented faster than individual "I
Good work!
But...
I think the test is not quite correct. ;)
I am talking about the command "COPY" in PostgreSQL.
In other words, I think that COPY and INSERT performed differently.
"COPY" must be implemented faster than individual "INSERT" into real Bacula Job.
I may be wrong.
To make the most c
Take a look to
trunk/gui/bweb/script/bweb-postgresql.sql and bweb-mysql.sql
function base64_decode_lstat();
Bye
Le Tuesday 07 October 2008 20:31:18 John Huttley, vous avez écrit :
> Yes,
> That was next on my list. Not something I've done before so I'm glad to
> hear that someone else has done
Yes,
That was next on my list. Not something I've done before so I'm glad to
hear that someone else has done it.
Where will I find this code?
Regards,
John
Eric Bollengier wrote:
Hello John,
An other solution that doesn't require any additional code and no database
structure modificat
Kern,
All detail I have is on the wiki, but to repeat,
add 2 datetime and a long integer sends the insert time from 520 to 532
minutes, an increase of 2.3 %
Size increase of DB too small to detect on my system, thus it is under 1%.
--john
Kern Sibbald wrote:
On Tuesday 07 October 2008 04:50:
John Huttley <[EMAIL PROTECTED]> writes:
>
> http://wiki.bacula.org/doku.php?id=wiki:playground
| "ctime Timestamp [...] The datetime it was created."
ctime is inode change time on Unix clients, and create time on Windows
clients. this difference alone makes the value of the field suspect.
--
Hello John,
An other solution that doesn't require any additional code and no database
structure modification, is to use a PL function to extract mtime, ctime,
size, block_size etc... from LStat field.
This function is available on Postgresql and now on Mysql (thanks to Kjetil).
The only draw
On Tuesday 07 October 2008 04:50:50 John Huttley wrote:
> Hi
> My first test are complete.
> To aid in getting all the questions/answers and results in one place,
> I've made a wiki entry.
>
>
> http://wiki.bacula.org/doku.php?id=wiki:playground
>
>
> My scripts are attached.
>
> --John
Can you pr
Hi
My first test are complete.
To aid in getting all the questions/answers and results in one place,
I've made a wiki entry.
http://wiki.bacula.org/doku.php?id=wiki:playground
My scripts are attached.
--John
gen_dumpfile: gen_dumpfile.o
gcc gen_dumpfile.o -o gen_dumpfile
gen_du
24 matches
Mail list logo