Complex stat creation questions

[Stally]

Hello,

I'm thinking about making a number complex stats that will pull data from a large number of columns (I suppose you could call them "compound stats", as they'll be referencing various things), and this will probably many times in one stat (so I think the coding lines will be extremely long and reference lots of columns many multiples of times). These will all be used on my HUD.

I don't (or at least at the moment) have any specific questions about the coding, rather I wonder if there are guidelines for how to go about making larger, more complex stats, when considering:

- the efficiency of the code and therefore how fast such data will be shown on a HUD.
- the efficiency and ease of coding, and understanding it when returning to it at a later point.

What about using the "variables"? I don't fully understand them, but I have experimented and found that you can put simple numbers into them, which can make stats easily customisable (instead of going through multiple stats and altering every reference to a specific number). E.g. I can set a variable to "=26" or "26" and use it by name when i need the number 26... but I then have the freedom to change "26" to something else. Does this create extra overhead for postgres, enough that I might be concerned?

What about when creating more complex stats - does it make sense to nest stats to make them more legible and more easily amended, or perhaps can the same thing be done with columns? If I am doing that with columns, would that slow down the housekeeping process and the HUD? Would extra stats (the nested ones) have the same effect?

I hope I explained it clearly enough so that you can provide some tips for me here.

Finally, I have a second, hopefully more basic question: Can I create a stat that looks at either a date range, or something like the last X opportunities? I know this feature is in the HUD itself to apply to the last X hands, and that you can create a database containing hands played within a date range, but I'm considering the idea of having the majority of stats cover larger areas for sample size (i.e. looking up results in the entire DB) but with a few special exceptions that I could code to have a limited focus. To give extreme examples, something like raise river -- which has a small sample and needs more time to be accurate -- compared to say RFI, where I feel it's really beneficial to use a smaller time period to have more accurate readings as the stat converges fast. Is there any way to limit the number of hands or dates looked at for my example of RFI?

Thanks for your time.

[WhiteRider]

I wouldn't expect any differences in structure to have a significant effect on performance, and I think good readable structure to your stats and columns will be more beneficial in the long run.

Using Variables is a good idea - they are basically used to do calculations which can't be done directly in PostgreSQL (e.g. adding column values, some mathematical operations, or storing constants as you've seen). These don't use PostgreSQL so don't affect performance in that way.

One thing to be wary of - do NOT use a column within another column. That will not work. (It's OK for Hand stats because each column value comes from a single hand, but in Player stats columns take values from all hands and re-using another column which is also a total value will cause problems. It's hard to explain, but stay clear! )

You can use date ranges in custom stats - for example, something like this should work:

sum(if[ localtimestamp - interval '10 hours' < cash_hand_summary.date_imported, 1, 0])

Obviously you'd need to include the expressions for the stat you're building too, but that should limit it to hands played in the last 10 hours (in this example). You can change the time period of course.

[Stally]

Thanks a lot!

Your response makes things a lot clearer, and that timestamp answer looks very helpful too.