Reputation
Top tag
Next privilege 200 Rep.
See reduced ads
Badges
1 10
Newest
 Teacher
Impact
~8k people reached

  • 0 posts edited
  • 0 helpful flags
  • 6 votes cast
Dec
16
comment Where/how do I save extra data per column?
Yeah, but I wanted to avoid confusion :)
Dec
16
comment Where/how do I save extra data per column?
It does minimize overhead, but I think I know what bugs me on it: see addition to the question: there is no separation between the two clearly different types of information, so when looking for all meta-information you'd have to manually type the right columns and feels like you are adding a hidden property to those colums; one that might be made more explicitly?
Dec
16
comment Where/how do I save extra data per column?
Well, on a table with say 15 columns, and some related table holding another batch of those, you'd get a lot of extra size to the table. I'm not sure why, but it feels cluttery.
Aug
28
comment Space usage when copying
As stated in the question, it's already mixed. Changing it to statement doesn't help me much: I want to figure out what exactly happened; changing binlog on a production server is not really going to help me there :)
Aug
27
comment Space usage when copying
I have fixed the query itself by the way, so that isn't a real issue: I am mostly wondering what queries would fill up the binlog this much, and why, so I can begin to learn when to expect this.
Aug
27
comment Space usage when copying
But then the replication would break, right? Sounds.. sub-optimal
May
13
comment Mysql reliable with 1000 new entries / minute?
What does mysql being open source have anything to do with it?
Apr
9
comment Mysql query is very slow
There is probably something to say for actually sharing the EXPLAIN?
Apr
9
comment Changing TEXT to VARCHAR
I'm not really getting all the information from your links right: you mean to underline the thought my text column will be saved "withing the page" as they are not really big, so a change to varchar will not help?
Feb
16
comment Do I need a locking read?
The problem is, I'm not doing this a lot of times, but it is being done concurrently. So maybe this function will run a couple of hundred times per day, but possibly 2 times per someID. I don't have a prefab list, as the requests happen seperatly. And that's where the problem is. someID is not unique, so the ingore doesn't help. The roundtrips are not a problem by the way, it has virtually no impact on the system. I think I might get away with trying to do it all in one query, but this will get tricky because of the non-uniqueness. I did find something I think, but need to check it first.
Feb
15
comment Do I need a locking read?
What I basically want is "other threads shouldnt insert this row until I'm done with my work". Should I lock the complete table? I only want to lock inserting that one row...
Feb
15
comment What would this non-'unique index with a unique search condition` query lock?
then maybe I don't understand 'range', but there is no range in the sense there could be gaps, is there? There will be a block on that col=2 condition, not on any PK, is there?
Dec
8
comment Can a trigger access the query string?
I have tried this, but the query I always get is the "SELECT info INTO" query. The CONNECTION_ID() does change, but it looks like the current id is always that of the select? Should I try and save the CONNECTION_ID() earlier in the process?
Sep
12
comment Internal reason for killing process taking up long time in mysql
I'll check that, thanks. Anyway, the kill-and-force-recovery seems to have worked, alhtough I couldn't stop the process. In the end I just did a kill -9 to be done with it.
Sep
12
comment Internal reason for killing process taking up long time in mysql
I just found that quote too, i'll try it. @insertion: you are right: it didn't even cross my mind it could take this long, so never considered any alternatives :)
Sep
12
comment Internal reason for killing process taking up long time in mysql
In short: I am fscked... Am I glad this is a test-environment...
Sep
12
comment Internal reason for killing process taking up long time in mysql
I think I get it, but what do you mean by that last sentence? That if I kill the thing, the recovery-phase might start the 'rollback' all over again? That wouldn't be good. I'm now just letting it run, but its getting towards 7 hours of run-time now, which is getting ridiculous-ish. Would you advice in favor or against killing the mysqld?