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