pganalyze/pgcon2023

TODO

lfittl opened this issue · 3 comments

lfittl commented
  • Write the src/datagen.py file.
  • Make examples/data_example.json a bigger instance that can be played with in reasonable time.
  • Implement the time limit.
  • Add asserts for data types/ranges (e.g., strictness), goal/rule names, etc.
  • Add the solver status to the results.
    • Optimal: A valid solution has been found, and it has been proven to be the best.
    • Feasible: A valid solution has been found, and it is perhaps the best, but it has not been proven so within the alloted time limit.
    • Infeasible: No valid solution has been found within the time limit (true?), or, it has been proven that no solution exists for the problem (does not apply with out subset of goals/rules here).
  • Describe the model output in the README.
  • Harmonize both models' outputs.
  • Clean up the code a bit and check if there are any TODOs left.
  • Add pgcon2023_slides.pdf once the slides are finalized.
  • Write some tests.
PhilippeOlivier commented

Some output fields will be missing in the pgcon2023 model:

  • Scans have no impact.
  • There are no existing indexes, so there is a single "Indexes" field, instead of two fields ("Existing Indexes" and "Possible Indexes"). Should we instead replace "Indexes" by "Possible Indexes" and have an empty "Existing Indexes" field? This would harmonize both outputs, but would not be as elegant for the pgcon2023 model. There are now existing and possible indexes, but the list of existing indexes is fixed (always selected in the solution).
  • Some fields will be missing from "Statistics" since there is no consequence, impact, etc (but the remaining fields are the same).
PhilippeOlivier commented

The final solver status (and the amount of time required to solve the problem) will not be reported in the output of this model, as it is not reported in the fully-fledged model.

lfittl commented

Some output fields will be missing in the pgcon2023 model:
* There are no existing indexes, so there is a single "Indexes" field, instead of two fields ("Existing Indexes" and "Possible Indexes"). Should we instead replace "Indexes" by "Possible Indexes" and have an empty "Existing Indexes" field? This would harmonize both outputs, but would not be as elegant for the pgcon2023 model.

I think we eventually want support for existing indexes in this model (even if we don't have support for consequences), so that they can be assumed to exist during the selection process (and we don't suggest indexes that already exist). Therefore I'd keep the structure similar to the fully-fledged model in this regard.

  • 👍1