meta user
network profile
| bio | website | automatem.co |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | May 5 at 20:47 | |
| stats | profile views | 14 |
|
Apr 24 |
awarded | Tumbleweed |
|
Apr 17 |
asked | MySQL shared server regular lockup |
|
Apr 7 |
comment |
Bi-directional replication for the same MySQL table Can you check if Multi master replication would work? dev.mysql.com/doc/refman/5.1/en/… |
|
Mar 31 |
awarded | Benefactor |
|
Mar 31 |
comment |
Speed efficient query for membership first joined, latest category from membership table (min, max) InnoDB engine..... |
|
Mar 30 |
comment |
Speed efficient query for membership first joined, latest category from membership table (min, max) fantastic! I have to wait 10 hours to award the bounty |
|
Mar 30 |
awarded | Commentator |
|
Mar 30 |
comment |
Speed efficient query for membership first joined, latest category from membership table (min, max) Thats what I tried in my original query, can you advise how to link max(start) with the derived table? |
|
Mar 30 |
comment |
Speed efficient query for membership first joined, latest category from membership table (min, max) Thanks, I've come to this conclusion as well. I wondered if there is a way to just use group by and joining the table again. The question is of course will this be faster. |
|
Mar 30 |
awarded | Promoter |
|
Mar 26 |
revised |
Speed efficient query for membership first joined, latest category from membership table (min, max) edited title |
|
Mar 26 |
asked | Speed efficient query for membership first joined, latest category from membership table (min, max) |
|
Feb 25 |
comment |
Update to session table slow @Adam yes all gone for this database. There is a second database, which has only about 400 session records at most, I don't think I want to trade another 256M of RAM for that as it happens less often. The amount of actual storage required for the long field is higher than I would have expected, but I think it is worth it. |
|
Feb 24 |
awarded | Scholar |
|
Feb 24 |
accepted | Update to session table slow |
|
Feb 24 |
comment |
Update to session table slow @Adam I had some thought about this server. Mostly queries are read-intensive and these queries have only turn up in the query log after I have done some optimisation of other read queries. So I believe turning the query cache would make us go backwards. Instead I have converted the long to a varchar(15000) and made the table of ENGINE=MEMORY. Nevertheless this answer was very exhaustive and brought me onto the right track. |
|
Feb 23 |
comment |
Update to session table slow @Adam C. Scott The table is InnoDB. I'll try turning the query cache off. Also will investigate other session storage options |
|
Feb 23 |
comment |
Update to session table slow @edze yes probably, actually maybe I should see what other session storage mechanisms are available |
|
Feb 22 |
comment |
Update to session table slow Hash key by itself doesn't seem to have any effect |
|
Feb 22 |
comment |
Update to session table slow Uhm ok thanks, I'm a bit confused about query_cache, which I need for my read queries, don't I? I also have lots of MyIsam tables. Top: 3068968k total, 2798312k used, 270656k free, 541936k buffers. Statement see above. For your final comment will have to find a maintenance window. I will also try the hash key. |
