Le 15 juil. 2015 11:16 PM, "David G. Johnston"
a écrit :
>
> On Wed, Jul 15, 2015 at 4:53 PM, Michael Nolan wrote:
>>
>> On Wed, Jul 15, 2015 at 3:16 PM, Robert DiFalco
wrote:
>>>
>>>
>>> Thanks David, my example was a big simplification, but I appreciate
your guidance. The different event types
On Wed, Jul 15, 2015 at 4:53 PM, Michael Nolan wrote:
> On Wed, Jul 15, 2015 at 3:16 PM, Robert DiFalco
> wrote:
>
>>
>> Thanks David, my example was a big simplification, but I appreciate your
>> guidance. The different event types have differing amounts of related data.
>> Query speed on this
On Wed, Jul 15, 2015 at 3:16 PM, Robert DiFalco
wrote:
>
> Thanks David, my example was a big simplification, but I appreciate your
> guidance. The different event types have differing amounts of related data.
> Query speed on this schema is not important, it's really the write speed
> that matte
On Wed, Jul 15, 2015 at 12:32 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> 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 late
On Wed, Jul 15, 2015 at 3:16 PM, Robert DiFalco
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
On Wed, Jul 15, 2015 at 11:15 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> Yes, you are trying to choose between a bunch of one-to-one (optional)
> relationships versus adding additional columns to a table all of which can
> be null.
>
> I'd argue that neither option is "normal
On Wed, Jul 15, 2015 at 1:56 PM, Robert DiFalco
wrote:
>
>
> On Wed, Jul 15, 2015 at 10:33 AM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Wednesday, July 15, 2015, Robert DiFalco
>> wrote:
>>
>>> First off I apologize if this is question has been beaten to death. I've
>>> l
On Wed, Jul 15, 2015 at 10:33 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Wednesday, July 15, 2015, Robert DiFalco
> wrote:
>
>> First off I apologize if this is question has been beaten to death. I've
>> looked around for a simple answer and could not find one.
>>
>> Given a
On Wednesday, July 15, 2015, Robert DiFalco
wrote:
> First off I apologize if this is question has been beaten to death. I've
> looked around for a simple answer and could not find one.
>
> Given a database that will not have it's PKEY or indices modified, is it
> generally faster to INSERT or UP
I
On Wed, Jul 15, 2015 at 12:16 PM, Robert DiFalco
wrote:
> First off I apologize if this is question has been beaten to death. I've
> looked around for a simple answer and could not find one.
>
> Given a database that will not have it's PKEY or indices modified, is it
> generally faster to INSE
On Wed, Jul 15, 2015 at 12:16 PM, Robert DiFalco
wrote:
> First off I apologize if this is question has been beaten to death. I've
> looked around for a simple answer and could not find one.
>
> Given a database that will not have it's PKEY or indices modified, is it
> generally faster to INSERT
First off I apologize if this is question has been beaten to death. I've
looked around for a simple answer and could not find one.
Given a database that will not have it's PKEY or indices modified, is it
generally faster to INSERT or UPDATE data. And if there is a performance
difference is it subs
12 matches
Mail list logo
