Re: slow queries over information schema.tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: slow queries over information schema.tables
Date
Msg-id 17422.1544118632@sss.pgh.pa.us
Whole thread Raw
In response to Re: slow queries over information schema.tables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: slow queries over information schema.tables  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Dec 6, 2018 at 12:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ further experimentation... ]  It looks like if you prepare
>> a query and then just execute it repeatedly in one transaction,
>> you'd not reach AIM (as long as you were getting generic plans).
>> Possibly that's a gap worth closing.

> If we called it at the start of every query, couldn't we dispense with
> the call in relation_openrv_extended()?

No.  You need to do AIM *after* obtaining the lock, else you still
have the race condition that you can execute a query on a table
without being aware of recent DDL on it.

What we could possibly do to close the gap cited above is to have
plancache.c's CheckCachedPlan force an AIM call if it notices that
the plan it wants to re-use has a non-empty PlanInvalItems list.
If it does not, then there is nothing that AIM would cause invalidation
for anyway.  This still leaves us with a query-duration-sized race
condition window for DDL on functions and domains, but not any larger
than that.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Lætitia Avrot
Date:
Subject: Alter table documentation page (again)
Next
From: Alvaro Herrera
Date:
Subject: Re: Alter table documentation page (again)