Forum Replies Created
-
AuthorPosts
-
peterlaursenParticipant
What I meant …
That memory usage builds up when moving program window around could be graphics related. But you are right of course that queries returning more rows that what is displayed should not cause any Graphics related issue!
peterlaursenParticipantNot reproducable either!
This is an very traditional Athlon PC with old Nvidia GF2/MX board, but with a recent Forceware driver.
peterlaursenParticipantI just edited another post of mine
Quote:I could suspect that this is related to the Graphics system/driver! I testet on my 'mini-PC' with a VIA graphics chip. I'll try with another system with NVIDIA graphics!Ten minutes!
peterlaursenParticipantAnd …
A simple SELECT returning about 40.000 rows of my music database makes SQLyog use about 20M RAM and 20 MB Swapfile. Next after another SELECT returning only one row if decreases to almost what it was when program was opened (HISTROY explains that it does not quite) When minimizing SQLyog RAM usage goes to around 340 KB.
I can do that repeatedly!
And actually HISTORY built-up is swapped by my system! Repeated queries increses Swap-file usage but not physical memory usage!
It is the same with and without that additional memory manager. Except that using it cutting about 25% in memory footprint with SQLyog. But there is no build-up in neither case!
I could suspect that this is related to the Graphics system/driver! I testet on my 'mini-PC' with a VIA graphics chip. I'll try with another system with NVIDIA graphics!
peterlaursenParticipantQuote:Start it, and start to move/resize SQLyog. You'll see…No! Not here! :huh:
peterlaursenParticipantI also can add that on my system (Win XP SP2) I can open SQLyog, move program window around, maximize, minimize etc – and memory usage according to Task manager does not change!
peterlaursenParticipantI also would add that extensive memory usage is no problem as long as it is available without the need for swapping and as long as no other program needs that memory! But the OS should free the memory when some other program needs it.
Modern Windows is not DOS! Memory management is quite different!
But I can recommend this program
http://www.yourwaresolutions.com/software.html#framxpro
for improving /additinal memory management with WinXP!
peterlaursenParticipant1)
A 'small memory build-up' will always occur as HISTORY grows. Actually about a year ago a program change was introduced, with VERY BIG queries. I don't remember details. But it was something like queries taking more than 4 KB was not added to HISTORY.
Actually I have proposed before that histroy was 'spooled' to a file. Then you also could close down the program and open HISTORY from a previous session.
2)
Will I need that 'proces explorer' program to reproduce? Task manager will do as well I guess? You are sure that it is not that 'proces explorer' program that smashes Windows Menory management?
peterlaursenParticipantI think that partitioned tables as of MySQL 5.1 could be interesting for you then?
Maybe you could 'trigger' the proces of implementing GUI-support for that with SQLyog?
peterlaursenParticipantQuote:If I seperate the drop table statment from my create table statement with a ';' it stops the query after the “drop table” and does not create the new table from the following select statement.Ok – there are two possibilities:
1) to execute 'current query' (single arrow icon or keyboard shortcut: F5)
2) to execute 'all queries' (double arrow icon or keyboard shortcut: Shift + F5)
Check program help .. keyboard shortcuts
peterlaursenParticipantBesides ..
You can also ALTER TABLE …
Then existing data are kept (unless you drop the column)
peterlaursenParticipantQuote:I've tried this series in my queryDROP TABLE PRODUCTS
CREATE TABLE PRODUCTS
SELECT …
First: If you have more queries they should be divided with “;” (semicolon)
Next: A new table must have at least one column. You could write then (just an example):
Quote:drop table products;create table products (`id` bigint NOT NULL AUTO_INCREMENT , `t` varchar (50) NULL , PRIMARY KEY ( `id` ) );
select ….
But why don't you use the GUI ?
1) Right.click a table .. choose 'drop table'
2) Right-click a database .. choose 'create table' SQLyog then generates the SQL needed. You can view it in HISTORY-pane
peterlaursenParticipantQuote:… from a table with 12+ GB of datathat is quite a large table. I think the index structure of the table in relation to the queries (is there an appropriate index for the query?) could be interesting.
But nothing that I know about in particular. I never had any table exceeding 20 MB.
peterlaursenParticipantConfirmed!
I consider this a simple GUI-bug!
peterlaursenParticipantYes, that is true that user management has 'stood still' since MySQL 4.0 – and that probably is too long. Well what can I say .. ' MySQL Administrator' does what SQLyog does not, and it will be like that for some months ahead. I can live with that – since I have to!
But the most important issue with SQLyog in my opinion is this one
Code:When saving data from the grid view of the DATA or RESULT -panes the grid shall be parsed for type (and maybe even functions) and column defaults such as NULL and (predefined) variables such as (to mention the most important one) CURRENT_TIMESTAMP... and this one will be fixed in about a month's time. Not overwriting column defaults unless user has explicitly done so himself is a matter of data integrity. And that this comes first is a correct decision in my opinion!
-
AuthorPosts