Re: Trouble incrementing a column

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Blake McBride <blake1024(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Trouble incrementing a column
Date: 2019-11-25 01:08:45
Message-ID: 17712.1574644125@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Sat, Nov 23, 2019 at 4:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Note that you pay a fairly substantial performance penalty for deferring
>> the check, which is why it isn't the default, even though the SQL spec
>> says it ought to be.

> Do you know what the worst case scenario is for the performance of
> deferring the check to the end of the statement (with deferred initially
> immediate)? Upon testing, I get a penalty of 2 to 5%, which seems pretty
> small, but I might not be testing the most adverse situation. See attached.

Hm, I would have expected more, though not factor-of-10 or anything
like that. But that's just vague recollection from when we put in
the feature. I'm not surprised if the numbers have moved since.

> The main "cost" that prevents from using DII routinely is that they can't
> receive foreign key constraints.

Yeah, that's an issue.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2019-11-25 04:14:28 Re: sql query for postgres replication check
Previous Message Jeff Janes 2019-11-25 00:51:11 Re: Trouble incrementing a column