Heikki,
> if you can tolerate losing a few last transactions in a power outage or an
> OS crash, you can set
>
> innodb_flush_log_at_trx_commit=2
Does that speed up the thing? I should make some testing.
> Have you shut down mysqld and restarted it after populating the tables?
> MySQL only upda
AIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Wednesday, October 01, 2003 6:04 AM
Subject: InnoDB speed problems
>
> Hi all,
>
> Because I want to use transactions in the future I have converted all
> tables of a copy of our production database server (1800+, 512 MB RA
Hi all,
Because I want to use transactions in the future I have converted all
tables of a copy of our production database server (1800+, 512 MB RAM,
Linux) to InnoDB format. No problem until now. First, let me show you
settings in my.cnf:
key_buffer= 16M
table_cache
On Wed, Sep 25, 2002 at 11:33:37PM +0300, Gergely Imre wrote:
>
> hi all
>
> i've mysql 2.32.52 installed, and there is a table with nearly 2.000.000
> records in it (4 field/record). i have 256megs of RAM, and the linux
> version is RedHat 7.3. i do a simple delete, like:
>
> delete from foo
Any reason you can't upgrade to a newer version?
mysql,query
DSL
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this threa
hi all
i've mysql 2.32.52 installed, and there is a table with nearly 2.000.000
records in it (4 field/record). i have 256megs of RAM, and the linux
version is RedHat 7.3. i do a simple delete, like:
delete from foo_db where foo>10; (this is around 15.000 record)
and after 30 minutes, still
On Thu, 15 Aug 2002, Benjamin Pflugmann wrote:
> Let me try to explain.
> Last, an introduction into LEFT JOINs:
Benjamin,
this was a very good explanation. I would love to see an edited version of
your post included in the "Tutorial" section of the very fine manual.
Regards,
Thomas Spah
Hi.
On Wed 2002-08-14 at 15:06:02 -0700, [EMAIL PROTECTED] wrote:
> If you were here right now I would kiss you! Well not really, but I can not
> believe what that did!! It takes around 2-4 seconds now for the query to
> execute completely! I wish I understood when to use what type of join sin
Hi
To help improve the performance, it would help knowing
- table structures, use show create table ;
- how many records in each table
- have all the tables being analyzed/optimized recently
Inner joins whilst very useful, do impact on performance. In some cases
it is more efficient to use a s
I wrote:
>> SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company AS
>> Comp, Jobs.JobID, Employers.EmpID
>> FROM Location
>> INNER JOIN JobsLocation ON JobsLocation.LocID = Location.LocID
>> INNER JOIN Jobs ON Jobs.JobID = JobsLocation.JobID
>> INNER JOIN Employers ON Employ
If you were here right now I would kiss you! Well not really, but I can not
believe what that did!! It takes around 2-4 seconds now for the query to
execute completely! I wish I understood when to use what type of join since
it is very obvious to me that it matters, and matters greatly! Thank y
On 14 Aug 2002, at 14:46, Richard Baskett wrote:
> Ok that saved me 5 seconds per query! So far so good! I couldn¹t use the
> STRAIGHT_JOIN though (received errors) so I made it an INNER JOIN. This is
> the new query:
You say the EXPLAIN output looks the same, so the 5 second savings is
just r
mysql to 3.23.51 and the problem was solved.
>
> Richard Baskett wrote:
>
>> Ok Im still having some serious speed problems and obviously since more
>> records are being added every day the problem is getting worse. Here is the
>> query:
>>
>> SELECT DISTI
what version of mysql are you running? I was having similar problem then I
upgraded my mysql to 3.23.51 and the problem was solved.
Richard Baskett wrote:
> Ok Im still having some serious speed problems and obviously since more
> records are being added every day the problem is getting
Ok that saved me 5 seconds per query! So far so good! I couldn¹t use the
STRAIGHT_JOIN though (received errors) so I made it an INNER JOIN. This is
the new query:
SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company AS
Comp, Jobs.JobID, Employers.EmpID
FROM Location
INNER
On 14 Aug 2002, at 14:09, Richard Baskett wrote:
> SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company AS
> Comp, Jobs.JobID, Employers.EmpID
> FROM Employers
> INNER JOIN Jobs ON Employers.EmpID = Jobs.EmpID
> INNER JOIN JobsLocation ON Jobs.JobID = JobsLocation.JobID
> INN
Ok Im still having some serious speed problems and obviously since more
records are being added every day the problem is getting worse. Here is the
query:
SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company AS
Comp, Jobs.JobID, Employers.EmpID
FROM Employers
INNER JOIN
On 2001-03-21, Viljo Marrandi <[EMAIL PROTECTED]> wrote:
> No, only one SELECT with 3 joins. Just in case i send this query again:
> SELECT f.foto_id, f.imgname, f.path FROM foto f, indeks k1, indeks k2
> WHERE f.foto_id = k1.foto_id AND k1.word = 'mati' AND f.foto_id =
> k2.foto_id AND k2.word
> [..] Why this is
> s slow with BSD we still don't know (like i said in my first mail,
> same query was 3 secs or ~20 sec on Linux)
I haven't followed the entire thread so feel free to diss me..
There was problem with the userland threading under early OpenBSD 2.8
versions (including the 's
Hello,
On Tue, 27 Mar 2001, Benjamin Pflugmann wrote:
> Could you try a binary from www.mysql.com at least for one of the slow
> machines and see if it makes a difference?
Well, it took some time, but at last i've found some time and tested it on
BSD machine. Binary from mysql.com has same spee
Hello.
Sorry about the delay, but I was side-tracked by a server crash at the
end of last week.
The EXPLAIN for the 3.23 MySQL is at least as good as for 3.22, (in
fact, it is better). As one fact, 996*1*1264=1258944 rows are less
than 986*1*1470=1449420 rows, but at least in the same magnitude
> Okay, that means, memory is no problem. And disks shouldn't be a
> problem either, because the table fits into memory. (Sorry, don't
> remember the test case anymore. Did it contain INSERTs/UPDATEs?)
No, only one SELECT with 3 joins. Just in case i send this query again:
SELECT f.foto_id, f.im
Hi.
On Wed, Mar 21, 2001 at 11:57:09AM +0200, [EMAIL PROTECTED] wrote:
> > Disk speed and memory is more relevant than CPU speed most times, so
> > you should include that info in your comparison.
>
> This is the fun part :). Machine which is the fastest with old mysql
> and Debian has IDE HDD
> Disk speed and memory is more relevant than CPU speed most times, so
> you should include that info in your comparison.
This is the fun part :). Machine which is the fastest with old mysql
and Debian has IDE HDD and 128 MB RAM, RH7 machine (dual PIII and new
mysql) has SCSI RAID and 512 MB RAM
Hi.
Disk speed and memory is more relevant than CPU speed most times, so
you should include that info in your comparison. And how big is your
table in bytes (not rows).
I would start with comparing the output of
mysqladmin variables
of all installation. Maybe some simply have a bigger key bu
Hello,
I encountered following problem: when using older mysql (3.22.23 vs
3.23.33) then older is about 4-6 times faster on the same machine. What
could be the problem? Sytem is Debian 2.2r2, older mysql was from .deb but
newer i built myself. The query looks like this:
SELECT f.foto_id, f.imgna
26 matches
Mail list logo
