Versions Compared

Old Version 3

changes.mady.by.user Nathan Southern

Saved on

compared with

New Version 4

changes.mady.by.user Nathan Southern

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. In last week, switch to PostgreSQL. Data engineer has been onboarded - he's working on loss records, Mr. Antley working on Premium and ETL to load Premium records. Table set up. Function distinguishing between dates (SQL server function).
  2. Two queries for calculating EP based on work over the summer - laid foundation for a very quick transition
  3. Observations
    1. We originally talked about utilizing year/month/day. The team didn't want to put a timestamp, but to keep things simple. However on this database engine, that creates a problem. Mr. Antley worked with this and couldn't get it to drop timestamp aspect. Mr. Antley asked if having extra precision on dates will cause issue. (Unsure about the exact source of this issue, i.e., auto add of timestamp). No concerns presented. Mr. Antley will discuss in AWG Monday. Mr. Harris noted the variable we get today is 3 digits - month month year. Asked how this will be transformed into date. Mr. Antley: AAIS handles this by assuming the 15th (mid-month accounting), and effectively adds a level of precision. For now everything will stay the same.
    2. 2b - numeric for data type. Car years - exposure x months covered / 12. Calculation for car years requires some division, auto generates four decimal places. Mr. Antley asked if team wants to do fixed decimal places. Are 4 decimal places enough? Should we cap everything off to round dollars/round #s. Mr. Braswell pointed out that this may be more of a formatting issue, or a question of how it is represented; asked if it is just a floating point #. Fine as long as numeric translates to a double.  Mr. Madison: per PostgrSQL manual it is not a floating point, but a user-specified precision. Mr. Braswell: level of precision depends on how/for what fraction will be used, in terms of how much it impacts the end line #s. 
    3. Mr. Madison: if we agree that we maintain the highest level of precision as long as possible into the processing, this is a solid guideline. Only downshot w/higher precision is cost. Mr. Madison advocated taking the performance and storage drawbacks to store it more exactly and avoid major end-line aberrations. 
    4. Mr. AntleyMadison: his main concern is that it's it's a business question to decide what level of precision we want to use (4th place, 10th place). 4 places feels comfortable. Simply rounding to penny is probably inadequate. 
    5. Group decided to run decimals to four places. 

Goals

Discussion items

TimeItemWhoNotes




...