Re: response time is very long in PG9.5.5 using psql or jdbc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: David Gould <daveg(at)sonic(dot)net>, 石勇虎 <SHIYONGHU651(at)pingan(dot)com(dot)cn>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: response time is very long in PG9.5.5 using psql or jdbc
Date: 2018-02-13 22:06:36
Message-ID: 7656.1518559596@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> I can obviously see problems with a bloated catalog, but how does that
> cause massive slowdowns in *individual* queries as we see here? The
> OP's problem isn't the connection establishment performance afaict, but
> the first query using specific pieces of catalog data. And that should
> be ok-ish performancewise, even if there's bloat.

Yeah, I'm confused about it too. I'm wondering if there's some
as-yet-unrecognized effect like the ones discussed here:
https://www.postgresql.org/message-id/flat/4F9AC452.3050102%40pgexperts.com
and here:
https://www.postgresql.org/message-id/flat/20120524173325.GA5533%40tinybird.home

Now, those issues seemed to be associated with needing to rebuild the
relcache init file, so you wouldn't expect them to repeat on every
connection ... but maybe the OP has something going on that causes the
init file to get invalidated constantly. That'd have to be on top of
some other massive performance problem, but at least you could see how
catalog bloat could possibly lead to this type of symptom, seeing that
init file rebuild requires some catalog seqscans.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2018-02-13 22:21:02 Re: response time is very long in PG9.5.5 using psql or jdbc
Previous Message Dan Goodliffe 2018-02-13 21:34:21 Re: BUG #15063: Updates to temporary tables fail when there is a publication with FOR ALL TABLES