Re: Insert vs Update

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Michael Nolan <htfoot(at)gmail(dot)com>
Cc: Robert DiFalco <robert(dot)difalco(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Insert vs Update
Date: 2015-07-15 21:14:42
Message-ID: CAKFQuwaDgwskDhA0qhXLiq2cB8WdHZYCw0RH7hU_utCOqp53bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Jul 15, 2015 at 4:53 PM, Michael Nolan <htfoot(at)gmail(dot)com> wrote:

> On Wed, Jul 15, 2015 at 3:16 PM, Robert DiFalco <robert(dot)difalco(at)gmail(dot)com>
> 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 matters. So I was just wondering given the INSERT or UPDATE approach
>> (with no indexed data being changed) if one is likely to be substantially
>> faster than the other.
>>
>>
> As I understand how ACID compliance is done, updating a record will
> require updating any indexes for that record, even if the index keys are
> not changing. That's because any pending transactions still need to be
> able to find the 'old' data, while new transactions need to be able to find
> the 'new' data. And ACID also means an update is essentially a
> delete-and-insert.
>

​I might be a bit pedantic here but what you describe is a byproduct of the
specific​ implementation that PostgreSQL uses to affect Consistency (the C
in ACID) as opposed to a forgone outcome in being ACID compliant.

http://www.postgresql.org/docs/9.4/static/mvcc-intro.html

I'm out of my comfort zone here but the HOT optimization is designed to
leverage the fact that an update to a row that does not affect indexed
values is able to leave the index alone and instead during index lookup the
index points to the old tuple, notices that there is a chain present, and
walks that chain to find the currently active tuple.

In short, if the only index is a PK an update of the row can avoid touching
that index.

I mentioned that going from NULL to Not NULL may disrupt this but I'm
thinking I may have mis-spoken.

Also, with separate tables the amount of data to write is going to be less
because you'd have fewer columns on the affected tables.

While an update is a delete+insert a delete is mostly just a bit-flip
action - at least mid-transaction. Depending on volume, though, the
periodic impact of vaccuming may want to be taken into consideration.

David J.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Guillaume Lelarge 2015-07-16 05:13:40 Re: Insert vs Update
Previous Message Michael Nolan 2015-07-15 20:53:10 Re: Insert vs Update