Re: Order of enforcement of CHECK constraints?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: fabriziomello(at)gmail(dot)com
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Order of enforcement of CHECK constraints?
Date: 2015-03-23 15:33:12
Message-ID: 1342.1427124792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com> writes:
> On Fri, Mar 20, 2015 at 4:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> We could fix it by, say, having CheckConstraintFetch() sort the
>>>> constraints by name after loading them.

> Isn't better do this to read pg_constraint in name order?

> - conscan = systable_beginscan(conrel, ConstraintRelidIndexId, true,
> + conscan = systable_beginscan(conrel, ConstraintNameNspIndexId, true,

Surely not. That would end up having to read *all* of pg_constraint, not
only the rows applicable to the current relation.

We could get the index to do the work for us if we changed it from an
index on conrelid to one on conrelid, conname. However, seeing that that
would bloat the index by a factor of sixteen, it hardly sounds like a
free fix either.

I really think that a quick application of qsort is the best-performing
way to do this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-03-23 15:33:22 Re: Zero-padding and zero-masking fixes for to_char(float)
Previous Message Jeff Janes 2015-03-23 15:23:00 Re: Table-level log_autovacuum_min_duration