I take that question back – someone helped me on StackExchange and
addressed it:
*> It appears that Postgres is smart enough to identify cases where indexed
columns are not changed , and perform HOT updates; thus , there is no
difference between having or not having key columns in update statement
Thanks Justin. Do you know if Postgres treats an UPDATE that sets the
indexed columns set to the same previous values as a change? Or does it
only count it as "changed" if the values are different. This is ambiguous
to me.
*> HOT solves this problem for a restricted but useful special case where a
On Thu, Nov 22, 2018 at 01:31:10PM -0800, Abi Noda wrote:
> In other words, is Postgres smart enough to not actually write to disk any
> columns that haven’t changed value or update indexes based on those columns?
You're asking about what's referred to as Heap only tuples:
https://git.postgresql.o
In other words, is Postgres smart enough to not actually write to disk any
columns that haven’t changed value or update indexes based on those columns?
On Thu, Nov 22, 2018 at 11:32 AM Abi Noda wrote:
> Given a table, `github_repos`, with a multi-column unique index on
> `org_id` and `github_id`
Given a table, `github_repos`, with a multi-column unique index on `org_id`
and `github_id` columns, is there any performance difference (or other
issues to be aware of) between the two bulk upsert operations below? The
difference is that in the first query, the `org_id` and `github_id` columns
are
