Hello,
I think following query would help you
For Ascending
select cpid,sum(score),team from j group by cpid order by sum(score)
For Descending
select cpid,sum(score),team from j group by cpid order by sum(score) desc
Thanks!
2009/1/7 Phil
> A question on grouping I've never been able to sol
On Wed, Jan 7, 2009 at 1:48 PM, Jerry Schwartz
wrote:
>
>
>>-Original Message-
>>From: baron.schwa...@gmail.com [mailto:baron.schwa...@gmail.com] On
>>Behalf Of Baron Schwartz
>>Sent: Wednesday, January 07, 2009 9:54 AM
>>To: Jerry Schwartz
>>Cc: mysql@lists.mysql.com
>>Subject: Re: Limit
At 01:07 PM 1/7/2009, David Scott wrote:
1) InnoDb
2) 5.0.51 on Linux
3) No, a Select with a bunch of Joins, a Where, group and order
4) 37 seconds
5) Yes
6) Show Processlist does not show anything, just the user, what are you
looking for?
David,
I was looking to see if the other queries
Oh and we increased the key_buffer_size=1200M (30% of ram) no change.
2009/1/7 David Scott
> 1) InnoDb2) 5.0.51 on Linux
> 3) No, a Select with a bunch of Joins, a Where, group and order
> 4) 37 seconds
> 5) Yes
> 6) Show Processlist does not show anything, just the user, what are you
> looking
1) InnoDb2) 5.0.51 on Linux
3) No, a Select with a bunch of Joins, a Where, group and order
4) 37 seconds
5) Yes
6) Show Processlist does not show anything, just the user, what are you
looking for?
2009/1/7 mos
> At 11:20 AM 1/7/2009, you wrote:
>
>> When we run a large query other queries start
>-Original Message-
>From: baron.schwa...@gmail.com [mailto:baron.schwa...@gmail.com] On
>Behalf Of Baron Schwartz
>Sent: Wednesday, January 07, 2009 9:54 AM
>To: Jerry Schwartz
>Cc: mysql@lists.mysql.com
>Subject: Re: Limit within groups
>
>On Tue, Jan 6, 2009 at 3:13 PM, Jerry Schwartz
>Description:
I'm installing a new instance of MySQL using 5.0.67 (source) and get
the following
from mysql_secure_installation:
Set root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privile
At 11:20 AM 1/7/2009, you wrote:
When we run a large query other queries start to back up when the large one
gets to the 'creating sort index' phase, this lock seems to affect the whole
server, all databases... does anyone know what may be causing this?
Thanks in advance
--
David Scott
David,
On Wed, Jan 7, 2009 at 6:20 PM, David Scott
wrote:
> When we run a large query other queries start to back up when the large one
> gets to the 'creating sort index' phase, this lock seems to affect the
> whole
> server, all databases... does anyone know what may be causing this?
>
More specifics
When we run a large query other queries start to back up when the large one
gets to the 'creating sort index' phase, this lock seems to affect the whole
server, all databases... does anyone know what may be causing this?
Thanks in advance
--
David Scott
Phil
>is there any way to modify this query so that it would
>return the team having the most entries?
See "Within-group aggregates" at http://www.artfulsoftware.com/queries.php
PB
-
Phil wrote:
A question on grouping I've never been able to solve...
create table j (proj char(3), id int
A question on grouping I've never been able to solve...
create table j (proj char(3), id int, score double,cpid char(32),team
char(10));
insert into j values('aaa',1,100,'a','team1');
insert into j values('bbb',2,200,'a','team1');
insert into j values('ccc',3,300,'
Claudio,
> ehmthe problems is exactly that. On production server you cannot stop or
> lock the server so I need
> the replication slave mainly for backups (actually MySQL replication is
> simply great for this)
Just don't rely on the slave to BE the backup. You can use it to make
it easier t
Hi Jed,
> If you are using LVM, you might consider snapshotting, however, doing a live
> snapshot without stopping mysql server would only work if you were copying
> only myisam tables. Mysql-hot-copy would probably be better, but either way,
> you need to flush your tables, which will briefly loc
On Wed, Jan 7, 2009 at 9:17 AM, David Giragosian wrote:
> On 1/7/09, Jim Lyons wrote:
>>
>> There are other factors. If a table is completely fixed in size it makes
>> for a faster lookup time since the offset is easier to compute. This is
>> true, at least, for myisam tables. All books on tun
On Tue, Jan 6, 2009 at 3:13 PM, Jerry Schwartz
wrote:
> Each account has multiple customers, and each customer has multiple sales. I
> want to get the top 20 customers for each account.
http://www.xaprb.com/blog/2006/12/07/how-to-select-the-firstleastmax-row-per-group-in-sql/
Keep reading, it ta
On 1/7/09, Jim Lyons wrote:
>
> There are other factors. If a table is completely fixed in size it makes
> for a faster lookup time since the offset is easier to compute. This is
> true, at least, for myisam tables. All books on tuning that I have read
> have said the CHAR makes for more effici
There are other factors. If a table is completely fixed in size it makes
for a faster lookup time since the offset is easier to compute. This is
true, at least, for myisam tables. All books on tuning that I have read
have said the CHAR makes for more efficient lookup and comparison that
VARCHAR.
On Wed, Jan 7, 2009 at 2:26 PM, Richard Heyes wrote:
> I still think a CHAR field would be faster than a VARCHAR because of
> the fixed row length (assuming every thing else is fixed). Perhaps
> someone from the MySQL list could clarify...?
Say that your column length goes up to 2000 bytes, but
>>So where's the advantage of VARCHAR ?
>
> Less space on disc = less data retrieved from disc = faster data
> retrieval - sometimes. If you have small columns, a small number of
> rows, or both, then char columns may be faster. If you have large
> columns of varying actual length, lots of rows, or
20 matches
Mail list logo
