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
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
I am using 3.23.51 also
"Dost thou love life? Then do not squander time; for that's the stuff life
is made of." - Ben Franklin
> From: Rahadul Kabir <[EMAIL PROTECTED]>
>
> what version of mysql are you running? I was having similar problem then I
> upgraded my mysql to 3.23.51 and the problem
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 worse.
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
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
20 matches
Mail list logo
