Quote:
Will the HM databases be indexed for efficiency?
I think it is safe to assume yes, if not then within a few days of the public beta finding it's way to knowlegable PGSQL people (matt42s was it that proposed the clustering etc. springs to mind here) I'm sure RVG will get some optimization feedback
Quote:
Dave, is there a really good reason why this shouldn't work? I've only been using PostgreSQL for a few months (I'm a SQL Server guy) but it should be ok, right? I wrap everything in transactions which should help as well. Let me know if there are some "gotchas" I need to be aware of!
I'm no where near expert enough to know, but IIRC the PT importer is NOT networks safe because it parses all hands then pre-computes all the primary/foreign keys required for the SQL INSERT statements, creating a big list of INSERTS with fixed ID values.
Thus if you have two machines running an import to the same databse, chances are they will compute the same <NEXT ID> for some table, and one or the other INSERT statemest will fail because of duplicate keys.
In the worst case one importer will INSERT INTO game, while the other does an INSERT INTO game_players with the keys matching, resulting in the summary and hand info for a given ID differing, and a borked database. So NEVER run more than one copy of PT across computers.
one solution is to use sub-queries to compute new primary key values in mid SQL statement, and using transactions repeat the query if it fails for any reason. e.g.
<font class="small">Code:</font><hr /><pre>
INSERT INTO game(game_id) VALUES ( ( SELECT game_id FROM game ORDER BY game_id DESC LIMIT 1)+1);
</pre><hr />
^^^^ off the top of my head, may well be erroneous
Do that the new game_id is computed upon each execution of the INSERT command, but this likely carries some (quite possibly significant) performance penalty...
As I say, just an example, and I am in no way a PSQL expert.
Again, sooooo looking forward to the 15th
dave.