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
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 `git
nserting, and not a
new index tuple, if and only if the update did not affect indexed columns.*
On Thu, Nov 22, 2018 at 2:40 PM Justin Pryzby wrote:
> 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
&g
t 7:44 PM Abi Noda wrote:
> 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.
>
> *
*Postgres version: PostgreSQL 10.3 on x86_64-apple-darwin16.7.0*
*Operating system and version: MacOS v10.12.6*
*How you installed PostgreSQL: Homebrew*
I have a table as defined below. The table contains 1,027,616 rows, 50,349
of which have state='open' and closed IS NULL. Since closed IS NULL fo
cost down, if it's set to the
standard 4 setting.
Ok, let me try this.
On Tue, Feb 19, 2019 at 5:51 PM David Rowley
wrote:
> On Wed, 20 Feb 2019 at 13:11, Abi Noda wrote:
> > However, when I index the closed column, a bitmap scan is used instead
> of an index scan, with sli
, 2019 at 9:37 PM Justin Pryzby wrote:
> On Tue, Feb 19, 2019 at 05:10:43PM -0700, Abi Noda wrote:
> > I have a table as defined below. The table contains 1,027,616 rows,
> 50,349
> > of which have state='open' and closed IS NULL. Since closed IS NULL for
> al
