On Wed, Jul 15, 2015 at 3:16 PM, Robert DiFalco <robert.difa...@gmail.com> wrote:
> The different event types have differing amounts of related data. > On this basis alone I would select the multiple-table version as my baseline and only consider something different if the performance of this was insufficient and I could prove that an alternative arrangement was more performant. A single optional date with meta-data embedded in the column name is usually workable but if you then have a bunch of other columns with name like: preparation_date, preparation_col1, preparation_col2, consumed_col1, consumed_col2, consumed_date I would find that to be undesirable. You may be able to put Table Inheritance to good use here... I do not know (but doubt) if HOT optimization works when going from NULL to non-NULL since the former is stored in a bitmap while the later occupies normal relation space and thus the update would likely end up writing an entirely new record upon each event category recording. David J.
