> > Yes, the creation of the tables is very database dependent > and was not > > designed for portability. In hind-sight, one could > probably make them > > much more portable. > > > > Foreign keys were initially used in PostgreSQL, but they slowed it > > down considerably -- by a factor of 2-10 if I remember > right ! As a > > consequence, they were removed since they are not used (see below). > > Hmmm... I'm kind of surprised there was such a huge > performance penalty (and much bigger then in MySQL/InnoDB). > Anyhow, if they are not used, dropping them from MySQL and/or > SQLite should speed up those two a bit as well...
FOREIGN KEYs are not supported in SQLite. It shares the extremely dangerous behaviour with Mysql/myisam in that it accepts the syntax without errors, and then silently ignores it. There is no way to know.... Anyway. About the speed. FOREIGN KEYs can be extremely slow if you don't have the appropriate indexes. IIRC (but not certain), InnoDB enforces that these indexes exist before allowing the relationship, whereas PostgreSQL didn't (I believe it does now). If an index was missing (or not properly ANALYZEd), that could certainly explain such a difference. //Magnus ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
