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
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 |