Tag Archive for 'primary'
yeswecanhas.com was in the New York Post a couple weeks ago. Unfortunately, it was in the first edition of that day’s paper, but not in subsequent editions, so it didn’t make it onto the website. But I just found it via a newspaper archiving service, and took the below screenshots.
My friend Josh and his wife went to caucus in Houston, TX. Here are his reports as they come in. He is using instant messenger from his phone.
update: audio file from when the wrong numbers were announced
In chronological order. Newest updates are at the bottom. Last updated 9:31 pm, eastern
– 9:10 pm –
- it’s pretty nuts - lost sign in sheets, ad hoc procedural decisions, etd.
- in the beginning, everyone was told they could sign in (indicating the candidate) and then leave
- if they didn’t want to be a delegate
- [my wife] did, so we stayed
- then, when the initial count of hillary voters for one of the precincts was off by an obvious order of magnitude… [update: see audio file above]
- now we’re doing resolutions
- 1 - impeach bush/cheney
- (didn’t see that coming)
- anyway - a bunch of signup sheets were missing
- and the chair suggested that we allocate the delegates based on who was still here (!)
- (a bunch of folks had left - I would have if not for [my wife])
- but then someone came out of the back with a bunch of sheets
- and they’re still counting
- there was zero control over the sheets
- so I don’t think we can be too confident
- - next resolution has to do with inaccurate vote counts in the past - hehe
– 9:20 –
- rats - hillary took both precincts
- but by a narrow margin
- the total vote counts sounded sane
- hundred twenty something total for one precint, hundred two for the other - but i’m going to count
- about 100 still in the room - makes sense to think about that many left
- back into 4 groups - one O & one H for each precinct
- now voting on delegates, after hearing resolutions
- there’s usually no competition for delegates.
- right now a green party convert is stumping to become an obama delegate
- our precinct gets 5 delegates for obama, and 12 people signed up for it ([my wife] among them)
- we also get 5 alternates (makes sense), and so the delegates are expressing which they want to be
- looks like we pared down to 10 and agreed to split off the alternates
- no vote needed, and [my wife]’s a delegate - we’re taking off (baby’s cranky)
Josh had this to say after he got home:
- John: well… from what you told me it seems like some pile of sheets came from nowhere
- John: magically
- yeah — someone had stashed them in the back
- John: or at least– they could have been pre-processed by some party before they made their reappearance
- there were enough signers present, and the sheets were in plain sight…
- that it would have been foolish to try large fraud, I imagine
- but the control really wasn’t there — one or more sheets could have been lost
- all the addresses and voter reg (or drivers license) numbers will be verified
- so from that perspective, it’s probably better than those damn machines we used for the primary :)
There are two aspects of how MySQL/InnoDB use a table’s primary key on the file system that have important ramifications for the key’s design:
- The primary key determines the order in which the data is physically stored in the main data file, aka “the clustered index”. Another way of saying this: the main data file is a B-tree index that directly contains all of a table’s columns, and the key on this B-tree is the primary key. This can result in one less I/O operation (compared to MyISAM) on many queries.
- The primary key is what is used to associate all of a table’s indexes with the main data file. So the primary key is replicated in every row of every index.
How to design your InnoDB primary keys:
- Do explicitly define a primary key, and make it numeric. If no primary key is specified, or a non-numeric column is used as a primary key, InnoDB will used its own internal auto-incremented row ID to link between the main data table and the other indexes. This row ID is 6 bytes. The biggest numeric type in MySQL, BIGINT, is 8 bytes, and the next smallest type, INT, is 4 bytes. So not only is this “hidden” row ID an entire extra redundant column, it is also bigger than the data type that would be used in the vast majority of cases where a primary key is explicitly specified. Furthermore, when InnoDB falls back to using this internal row ID, the rows in the main data file are ordered by insertion order instead of your primary key, rendering InnoDB’s clustering behavior useless, and adding an entire extra I/O operation on some queries. This is a big loss.
- As alluded to above, the primary key should be sequential. Because the structure of the data on the disk is dictated by the primary key, it should be sequential, to avoid extremely expensive I/O on writes (when the B-Tree has to be reorganized), and to take advantage of the native clustering.
- The primary key should be as small as possible. Because the primary key is replicated in every entry of every index, designing the primary key to be as small as possible impacts the efficiency of all the indexes.
Using these 3 simple guidelines on a well-designed schema, InnoDB can perform at its full potential.
Above I mentioned that the primary key is stored in every row of every index. This includes the entire contents of a multi-column primary key. In a future article I will discuss scenarios/designs that can take advantage of this behavior.
Latest Comments
RSS