From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Robert DiFalco <robert(dot)difalco(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Insert vs Update |
Date: | 2015-07-15 19:32:18 |
Message-ID: | CAKFQuwbrSvT=AhsajQs1GM7D4_TudduztzVmovdw2_Dj94iaPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Jul 15, 2015 at 3:16 PM, Robert DiFalco <robert(dot)difalco(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert DiFalco | 2015-07-15 19:49:31 | Re: Insert vs Update |
Previous Message | Robert DiFalco | 2015-07-15 19:16:43 | Re: Insert vs Update |