i dont know if there is a correlation, but since i updated pp yesterday, pokertracker has gotten insanely slower and froze on me.

With all due respect. Lets keep on the topic at hand. Discussion for the next generation of PokerTracker, PT3. There is a dedicated forum to support the current version of PT.

Yeah, PAHud could have done the 3-bet stuff. The info is there in the database if you step through the hand and recreate the potstate between player actions. You can't do it with a simple SQL command, you could probably do it with PL/pgSQL but you can do it easily with code. I've done it with about 150 lines. There are a few rare cases which are difficult to decipher but they are extremely rare - they all involve more than two players acting on a given street, more than one player raising and one of the players raising, calling and folding OR calling, raising then folding. Like I said - rare.

Just for the record, I've been a strong supporter of PT for years and donated to PAHud before it was named. The support has always been fantastic for both products but is also what has hurt the development of the products. The next generation should have started before PAhud went to sqlite.

I don't mind paying double for both versions of the software, as it takes extra coding, and extra support. But it would be really nice if they were combined into a single program, so that we could see our results grouped together.

I'd prefer to keep them as separate programs but maybe that's just me. Nice for datamining one while playing the other.

You are right. It could have been done. We (PAH) visited 3bets prior to our implementation of the cache; therefore it was unrealistic based on computational usage to include 3-betting as an available statistic. It would be much more feasible to do now that we are using a cache; however, it would still be extremely processor intensive during the cache building process and cache updates.

With our new design of the PT3 database, 3/4 bets will take no more work than any other stat therefore will be much more realistic and a definite addition.

Ideally, maybe. Unfortunately, there is a lot more involved with PT3 then just development. There is a business side with two separate parties involved. It would be nice to make PAH's cache in Postgres; however, we will need to weigh the benefits of each. Postgres is known as feature rich database but it isnt the fastest db in the world. For a small db such as PAH's cache; SQLite may be the better choice. We've yet to test and determine. Speed is our number one goal...

Best regards,

APerfect10

I have a feature suggestion: be able to import notes on players from the poker site into the PT database. That would be very useful when reviewing hands.

Use the "import/export notes" somewhere on pt menubar; only works for text sites like stars and whatever ones are listed (abs is still listed but has been non-text for many many months so don't use it).

please dont integrate 3-betting and 4-betting into this.

I'm probably being leveled but it will be in there. If you dont want it you dont have to have it. <Subtle hint>

Never knew that was there. Unfortunately there isn't support for FTP yet. I guess this is because the notes aren't saved in a simple format. However, I know they can be found in the [username].dat file in the FTP folder. I wonder if some of the code can be deciphered so that it would be able to be imported?

For complicated queries postgre is one of the best free db engines out there. For non-complicated, quick and to the point queries it slacks pretty bad though -- mysql will tear it apart in most cases.

Perhaps PT v3 could be designed with db simplicity in mind, and move over to mysql?

MySQL... you jopke surely???

It is at least a sensible option compared to the suggestion of MS SQL Express with the 2GB RAM / 1 CPU restrictions

Without loading up on MsSQL Vs. PGSQL flamewar ammunition lol, MySQL is out because of weirdo licensing conditions... PT can not link against mysql without becoming GPL, unless fork out silly $$$$$ to license MySQL AB or something like that - I can't remember a great deal from the old PT forum threads.

Besides, I'm fairly sure RVG just demonstrated PGSQL can be plenty fast enough for a tracker app once the SQL is wrapped in transactions etc. - I still stand by my earlier statement that PT's database speed problems stem from the MS Access default / going through ODBC - I believe vast performance increases could be achieved if that was dropped for version 3, alternatively totally seperate code used to read/write different DB engines.

Would be very interesting if PT & PA-HUD abstracted the DB layer somehow (PERL maybe?), thus allowing the user to implement almost any DB backend... then we could see some seriously interesting DB performance comparisons etc.

Very much looking forward to a new generation of apps

dave.

Yeah. I have a DB with nearly 30k hands (I know, not very many). Originally it was access. Speed wise, I had no complaints. It was fast enough that it wasn't annoying.

But I switched over to postgre because I wanted to fiddle with HM. After converting my PT db to postgre it was like a totally different app speed wise (for the better).

I won't get into any flamewars, don't worry.

I never looked into mysql licenses since most of the work I do with it is hosted on web hosting services or personal local use.

I do recall an article not too long ago that showed mysql really doing well with simple queries compared to many others.

Btw please never mention the word Perl again when talking about implementing it as a middle man.

You say most cases, but it would be very difficult, if not impossible to write an application such as PT using non-complicated queries. Subqueries and joins are required for nearly every useful operation and mysql falls over pretty quickly in those circumstances.
The licensing isn't a trivial problem, either open the source to PT, pay $600 per server per year or run the risk of a court battle.