fenway

You should really re-write that as a proper join.

What happens if the computer is shut down before it's written then? It's write-cached... this is a general I/O technique, not specific to mysql... don't worry about it, unless your server crashes, you'll be fine (hence InnoDB has a proper binary log and it really never matters). Yes. The indexes take a few seconds per table to generate, and MySQL should only need to be restarted once in a few months. You said this before... how big are you tables? I find it hard to believe we're talking about seconds. And "should only" is wishful thinking. Sorry. I thought someone said earlier that the indexes are loaded at startup. They're not? Well then that's obviously a huge performance problem for selects isn't it? So all the more reason, I think. No, it's a huge performance problem to load the indexes for 300K+ tables if you haven't issued a single query yet (for example). Did you read about the LOAD CACHE INTO INDEX in the link I provided? You definitely don't have enough RAM for *all* of the indexes all the time -- no one does (have you tuned your server variables to make this true?). And besides, you can't possibly be grabbing all of the data out of the index anyway -- just a few fields perhaps, and maybe for some covering indexes -- but the rest of the data is on the disk, so you'll have to load it regardless to get the "actual" data. An index is basically just a hash (fine, InnoDB is a bit different, but still). The MySQL Performance Blog will give you hundreds of examples that are disk-bound vs. memory-bound, independent of the server set-up. That's just how it is. Basically, the answer is that you can't (not only that you shouldn't) -- you can pre-load indexes on-demand (though I think it's per table, not per key) manually, but that's about it. Moreoever, this shouldn't concern you... I highly doubt that you're referring to a specific query that you're trying to optimize -- and those can be dealt with on a case-by-case basis. You don't have to take our word for it... but that fact that mysql doesn't have such an option should suggest that it's not possible because it's undesirable and inefficient, not that it's some big secret that you have to pay for.

Because correlated subqueries are expensive -- you need to run it once PER ROW.

There's a whole sticky dedicated to this topic.

IE only... FF decide fonts are a security risk.

select seats - ( select count(*) from table2 where table1_id = id ) from table1

You can deal with time-based constraints differently....

Yes, but that doesn't mean it happens instantly... and even if it did, it would be minor. A few seconds per MONTH? Your'e kidding, right? Try rebuilding an index on a table with a few million rows. We're talking minutes, here, each time!!! Says who? They aren't loaded until you need them... and there's only a certain amount of space allocated for indexes in memory. So which ones are loaded depends on which tables you queries you decide to query, and how often relative to each other. Yes, there are way to coerce mysql to loading some first (read this article), but the storage engines are usually quite good about this. Then there's the query cache too, which operates on a totally different level. To summarize -- don't bother.

What's "emailShow"? Why not just .push()/

The index has to be loaded initially from a file -- you don't want to generate this constantly. Whenever you change a indexed field, it has be updated (either memory or disk)... and if the server dies, it's quite expensive to build this from scatch (try running ALTER TABLE DROP then ADD index on a big table). So it updates both. Very little I/O here... besides, I'd imagine these are write-cached anyway. Assuming you don't write to the table, the index will generally stay in memory anyway (assuming reasonable page buffer sizes, optimized tables, yada yada) -- mysql will handle this for you, don't worry about it.

The last value wouldn't be 9... whatever. Why do you want to do this?

I haven't had a chance to delve into the code (at "real" work), but it sounds like the IE rendering engine calculates the position on the page mid-load (or jumps mid-load... same thing).

I *really* don't want to get into the table thing... simply stating that IFRAMEs are prefectly reasonable as an alternative to AJAX (in fact, there are many things that AJAX can't do than IFRAMEs) can. But I agree with you that using frames for layout is a poor design choice.

Rest assured that all of the "authorities" have been notified... just don't hold your breath.

CSS media style sheet?

Or you can think of it as latin, since it is.

The internet police don't really exist.

(1) Read this sticky.. (2) Upload where/how? We have tightened up security due to some recently attempts to compromise these forums and the site in general, so bear with us. (3) We have been offline intermittently, so it's possible that we're getting higher traffic than usual... we're still working out issues related to (2).

That's like saying TABLEs are outdated. They don't have to "look" like anything, they're invisible, remember? And since when does AJAX work with SEO?

Don't have IE when I'm sitting right now... is this ID on a relatively positioned element?

Huh?

That's still with a subquery.... you need to join on the derveid table.

sounds like day number since the epoch plus fractional days.

Replace date = ( your sequery ) with date IN

You can't... maybe with a MEMORY/HEAP table.