Re: find_inheritance_children() and ALTER TABLE NO INHERIT

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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