| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: find_inheritance_children() and ALTER TABLE NO INHERIT |
| Date: | 2015-12-03 04:09:16 |
| Message-ID: | 9532.1449115756@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> Currently find_inheritance_children() is smart enough to skip a child
> table that it finds has been dropped concurrently after it gets a lock on
> the same. It does so by looking up the child relid in syscache. It seems
> it should also check if the table is still in the list of children of the
> parent. Doing so by scanning the pg_inherits(inhparent) index may likely
> be inefficient. So, how about adding that syscache on
> pg_inherits(inherelid, inhparent) [1]?
I doubt that a syscache would fix the performance issue there; it wouldn't
get referenced enough to be likely to have the desired tuple in cache.
I wonder whether we could improve matters by rechecking validity of the
pg_inherits tuple (which we saw already and could presumably retain the
TID of). There is at least one place where we do something like that now,
IIRC.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2015-12-03 04:19:30 | Re: [COMMITTERS] pgsql: Refactor Perl test code |
| Previous Message | Haribabu Kommi | 2015-12-03 04:00:24 | Re: pg_hba_lookup function to get all matching pg_hba.conf entries |