Обсуждение: Want to run PostgreSQL on new associative memory technology
My name is Tim Melchior. I am an engineer at UTMC Microelectronic Systems. I am considering modifying PostgreSQL to exploita new hardware technology that we have developed. I would appreciate any information or suggestions anyone couldgive me. I am particularly interested in contract/consulting resources that anyone might be able to suggest. My objective is to bring to market a new paradigm breaking associative memory technology which UTMC Microelectronic Systemshas developed. With simple cursor operations, we have benchmarked our hardware at 6000 times faster than MicrosoftSQL Server. What we lack is the ODBC and SQL interfaces to this hardware. Our e.Card Distributed Query Processor is a PCI card which employs two of our content addressable memory engine ICs (originallydeveloped for telecom routers) and a fully programmable 64 bit MIPS processor. The resulting product is essentiallya database kernel that performs at router speed. I believe that this product has enormous potential for highperformance database applications. Each card can store up to 2 gigabytes of memory. (see http:www.utmc.com/ecard/ formore information) Any suggestions that anyone can give me would be greatly appreciated. Thank you, Tim Melchior Sr. Principal Engineer UTMC Microelectronic Systems Colorado Springs, CO melchior@utmc.aeroflex.com 719-594-8162
After moving a database to a new machine, I tried a vaccum analyze, and get "ERROR: Tuple is too big: size 8180, max size 8140". I know that there's a limit on the tuple size and all of that - my question is: How do I fix it? Vaccum analyze barfs, as does trying "\d table name". I tried it on both machines, and the same thing. I suppose that I could write a parser to go through the pg_dump and find offending fields, but I'm hoping that there's a way for PostgreSQL to fix it. If there isn't a way for it to fix data that it's created, that's scary. : ) It is postgresql 6.5.3. steve
Steve Wolfe wrote: > > After moving a database to a new machine, I tried a vaccum analyze, and > get "ERROR: Tuple is too big: size 8180, max size 8140". > > I know that there's a limit on the tuple size and all of that - my > question is: How do I fix it? Vaccum analyze barfs, as does trying "\d > table name". I tried it on both machines, and the same thing. > > I suppose that I could write a parser to go through the pg_dump and find > offending fields, but I'm hoping that there's a way for PostgreSQL to fix > it. If there isn't a way for it to fix data that it's created, that's > scary. : ) It is postgresql 6.5.3. > Me too. It's been happening for the last weeks with a database that didn't have any problems before. By experimenting, I've observed that this behaviour disappeared when I removed a certain table that another co-worker created; the problem is that such table doesn't have any tuple bigger than the max. supported size. Looking at the data stored in it, I don't see anything bigger than 8000 bytes (more or less) either. We are using that table (and others) to store texts, in field defined with varchar(8000). I suppose that if somebody had tried to insert a text bigger than that, the database would have refused with an error... Just in case, is there any character that, when inserted, will make the tuple grow beyond the maximum size, while still taking technically just one byte? (Some of the inserted texts were Front Page-generated HTML, and had all kinds of tabs, return carriages and such). Paulo Jan. DDnet.