Re: slow queries over information schema.tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: slow queries over information schema.tables
Date: 2018-12-06 17:12:17
Message-ID: CA+TgmoYrs92UR6dEuzVp-ghuj0HAhZ0iyqb3memusje9Rr3uaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 6, 2018 at 12:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In my testing, that still hits AIM() during parserOpenTable().

Oh, I see. relation_openrv_extended() calls it.

> [ 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()? On net, that would actually
mean fewer calls to AcceptInvalidationMessages(), assuming you
sometimes run queries that touch multiple relations. And the behavior
would be more predictable, too, because you'd (hopefully) have no
cases where a command failed to see the results of DDL that committed
before the command was issued.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-12-06 17:12:44 Re: proposal: plpgsql pragma statement
Previous Message Pavel Stehule 2018-12-06 17:05:33 Re: proposal: plpgsql pragma statement