Waiting for a mobile device to die....

The Problem:

I strikes me as my Samsung PMP slowly dies next to me that waiting for a mobile device to die these days is very much like baking.  Like how opening the door on a delicate suflay do check if it's done would ruin it, if I keep waking the Samsung up to check how much is left I simply drain it more.  The screen is the biggest battery drain of all.  So a couple of things wind me up about this situation.  One is that the only connector (apart from the headphone jack) is this proprietary Samsung crap - so I can't plug it into one of my abundant USB ports I have lying around.  For crying out loud, my alarm clock has 2 in it!  The other thing that does my head in, is that these devices that are running out of battery seem to go out of their way to drain themselves telling you.  Thus hastening their demise considerably.

The solution:

Okay, there are two simple answers to end this nonsense.

1. Use standard USB ports everywhere.  If this isn't suitable for the device (due to form factor) then introduce a third form factor to USB (to compliment the two USB already has) that has a slimmer profile.  

Of course a better solution might be to actually adapt the other existing port these devises have.

2.  Many of the devices I'm talking about all have a standard 3.5mm mini-jack... or headphone socket if you will.  So why can't that supply power, just like USB does?   Think of the benefits!  Devices could charge each other!  I wonder what the complications of sending a charge over the same wire that's carrying signal.  If that weren't possible, then it would mean a redesign of the 3.5mm plug/socket spec, which probably makes it infeasible.

Oh well.  My device is still running, and hopefully the suflay is not ruined.  Oh yea, and on these stupid devices that constantly alert about dying... make them smart. Put them in low power mode (at the least dim the screen). Have a semi-awake mode where the first stage wakeup is just a dim power read out.  To wake fully, just press on again.

Bet's on any of this actually happening....

Temporary tables, union and union all

Temporary tables, union and union all: "Both UNION and UNION ALL use a temporary table to buffer results from all branches of the query. The temporary table buffers all rows before any are returned to the client. For UNION, a unique index is created on the table. For UNION ALL, a unique index is not created. The HEAP (MEMORY) engine is used as long as there are no LOB columns.

The HEAP engine uses fixed length rows. For variable length columns each row allocates the max size per column so a lot of memory can be wasted. When the temp table gets too big, it is converted to a MyISAM table. The switch is done when the size of the table is min(max_heap_table_size, tmp_table_size) (I think that equation is right, wouldn't it be nice if it were simpler?).

In some cases UNION ALL can be used to reduce network round trips when there are multiple SELECT statements that return similar columns: select * from foo UNION ALL select * from bar. While this reduces network latency, it can increase the load on the server from writing the temporary table.

A feature request might be open to not use a temporary table for UNION ALL. Search for more details on this topic.

What happened to the change to not allocate the max length for variable length columns in the HEAP engine? When will it appear in an official release? There is a feature request for it.

And now, a quiz from Domas. What is done for the following?

(select * from foo UNION ALL select * from bar) limit 10

PlanetMySQL Voting:
Vote UP /
Vote DOWN"