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.

It stems from Pat knowing little about databases when he wrote PT.
I though you would have known this dave.

You basically repeated what I said. Postgres is feature rich and can do a ton more but it isnt the fastest.

Sorry, MySQL is not an option. For two reasons:

1. As dave pointed out, their licensing will not work.
2. I believe Postgres is far superior to MySQL and I have a ton of experience with both. I prefer MySQL for web backend but thats about it. For a stand alone app, with the database the size of a potential poker database, Postgres is by far the better choice.

Access will also not be a part of PT3. I also believe that MSSQL will not be an option because we want PT3 to be portable. We have something up our sleeves =)

Why all the perl bashing? Perl still has its place...

I datamine a fair few hands and use the "don't store the actual hand history option". It would be nice for users who use this option to be able to "trim" their observed hand db. For example, you could have an option along the lines of "delete all observed hand statistics for any one player over and above 2000 hands. This would insure that the stats on all players are recent and allow a far more complete db overall.

The problem with this though is that individual hands affect everybody who was at the table. Say you have player x with 2k hands and you only want to keep the most recent 2k hands. If somebody at the table has less than 2k hands do you delete their hands as well? I might be missing something but I thought that was the reason why you can't do that currently with PT.

But they are hands where the hand history is not kept, so the stats are just individual stats that exist for each player seperately without the hand history once the hand has been processed and deleted- so these statistics don't exist in relation to any other player.

My suggestion for PT/Pahud: add a better postflop looseness measure. It should be simple like the preflop looseness measure VPIP.

Have you checked out PAH's Aggression Frequency? This is a much nicer and easier to deal with number then Aggression Factor. PT3 will most definitely contain Aggression Frequency as well as any other stat currently available in PAH but not in PT.

Yes, I have always used Aggression Frequency and I agree that it's better than PT's Aggression Factor. The preflop agression and looseness measures are fine, as is PAHUD's postflop aggression measure. A good, simple postflop looseness measure is what's needed. I suggest simply the percent of the time that a player calls bets postflop.

That's right about ftp. But I heard somebody somewhere say half the ftp notes file is on our computer and the other half is on ftp's machines - that sounds kind of screwy but if true ftp support might not be possible.

I did put in a request to support non-text sites somehow because I REALLY rely on my notes and hate for places like ftp I can't change/add to them offline in replayer (or even see them offline for that matter).