I'm about 99% positive this won't happen unless someone can come up with a db schema that won't fall over itself because I know with that additional storage with how many profiles we have falls way outside of my db design abilities.

Well, many users have the same monitor, so we could store the edid blocks in a separate table and use a hash of the edid block as a key into that table.

I would suggest to do both of:

 - Store the raw data (128 or 256 bytes x <n> x 10^6 - probably less than a gig)
 - Store the display size and maximum resolution split out, since those are the only things we actually care about, and having them split out will allow analysis without having to parse through the raw data. Say, encoded as two strings '1024x768' and '32x24' (< 20 bytes per profile)

The second is really what we care about, the first in addition would give additional flexibility for the future.

Mike, do you have a block park idea how many bytes per profile of storage our current infrastructure can handle?  EDID isn't normally that big, anyway.  my xorg.conf has this:

intel(0): EDID (in hex):•
intel(0): ⟾00ffffffffffff004ca3574400000000
intel(0): ⟾00110103801e13780a87f594574f8c27
intel(0): ⟾27505400000001010101010101010101
intel(0): ⟾010101010101b125a018518423302e46
intel(0): ⟾99002fbe100000190000000f00000000
intel(0): ⟾00000000000000000000000000fe0050
intel(0): ⟾593730370331343157440a20000000fe
intel(0): ⟾00202d38435c7da5e102010a202000f3

It's ~128 bytes per record.  Occasionally 256.  Very very rarely more.

That's still fairly large for 1e7 records, so you'd want a normal form of something like:

(vendor, model, serial) -> (complete block with serial number fields stripped)

Which would be eight bytes for the identifier tuple plus a reference to the complete block, times a few million, plus a few thousand complete blocks at n*128 bytes apiece.

This is megabytes, not gigabytes.  I'm happy to write the EDID parser to do the uniqueness stripping if needed.

Show me what one record would look like in a database look like, what type of search index would we use, etc, etc?

If you guys could get one record together and patch the smolt db schema I'd have a better idea of what you're wanting to do.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

EDID blocks are binary blobs.  Most of the data contained within is not really that interesting to decode from within smolt itself, I mostly want this for mining purposes.  So the goal here is dense storage, not so much decoding.

After the initial eight byte header, there's two uint16_t's that uniquely identify a given make and model.  For example, 10ac 1640 is my Dell 3007WFP.  The next four bytes are a serial number that is usually but not always unique; and there's another optional field for serial number later in the block.  There's also a week/year stamp as the next two bytes, and a checksum as the 128th byte.

So on the way in, you'd want to strip out the uniqueness information: mandatory serial number, checksum, and optional serial field.  You'd also like to strip out and store the week and year info as a range.  So the final sanitized EDID would look something like:

CREATE TABLE `edids` (
  `id` int NOT NULL auto_increment,
  `vendor` int default NULL,
  `model` int default NULL,
  `date_low` int default NULL,
  `date_hi` int default NULL,
  `blob` varchar NOT NULL
)

So the (online) queries you'd like to run are:
- How many people have this vendor's monitors
- How many people have this monitor
- How long was this monitor in production
- What's the sanitized EDID for this monitor

The bulk mode dump you'd like to get out is the above four questions answered for every sanitized EDID we know about; if that's oppressive, a simple dump of every sanitized EDID is fine too.

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.