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
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 |