Quote:
Originally Posted by garvin
I am not saying this is due to faulty implementation of SpadeEye (nor of PT3), but probably due to the enhanced information structure stored in PT3.
Thats exactly what i think, too.
Nevertheless, here is the SQL Query.
Maybe you see a big leak?
"SELECT count (hhps.id_player),
SUM (hhps.amt_won),
SUM(case when (hhps.flg_vpip) then 1 else 0 end),
SUM(case when (hhps.cnt_p_raise > 0) then 1 else 0 end), SUM(hhps.cnt_f_raise) + SUM(case when (hhps.flg_f_bet) THEN 1 ELSE 0 END),
SUM(hhps.cnt_t_raise) + SUM(case when (hhps.flg_t_bet) THEN 1 ELSE 0 END),
SUM(hhps.cnt_r_raise) + SUM(case when (hhps.flg_r_bet) THEN 1 ELSE 0 END),
SUM(hhps.cnt_f_call),
SUM(hhps.cnt_t_call),
SUM(hhps.cnt_r_call),
SUM(case when (hhps.flg_showdown) THEN 1 ELSE 0 END),
SUM(case when (hhps.flg_won_hand AND hhps.flg_showdown) THEN 1 ELSE 0 END),
SUM(case when (hhps.flg_f_saw) THEN 1 ELSE 0 END) FROM
holdem_hand_player_statistics hhps, player p
WHERE hhps.id_player = p.id_player AND p.player_name = 'Testname'
GROUP BY player_name"
Quote:
I guess the only other way to go is some advanced caching solution, or to create an intermediate DB a la PTAGG. But it would be good if it could work with current app structure because it is so smooth to use.
Agree.