| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Order of enforcement of CHECK constraints? |
| Date: | 2015-03-24 07:16:06 |
| Message-ID: | CAApHDvqcVW8G8JbjDJS3VsvubR62jYkbSg8VJDb4J9nEdxKBxw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 24 March 2015 at 17:51, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
wrote:
>
> In case of million inserts or bulk load with constraints on, these few
> cycles spent in ordering the constraints might be problematic, unless the
> ordering happens only once for a series of inserts.
>
As far as I can see this sort only occurs when a new relation is loaded
into the relcache. Relations are cached in the relcache when they're
accessed for the first time in each backend, and the cache will be
invalidated when the current backend or another backend perform DDL on that
relation.
Without relcache we'd need to lookup the system catalogs for just about
every SQL statement... This would be very slow indeed!
Regards
David Rowley
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thom Brown | 2015-03-24 08:53:06 | Error with index on unlogged table |
| Previous Message | Andrew Gierth | 2015-03-24 07:03:39 | Re: Abbreviated keys for Numeric |