| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | David Gould <daveg(at)sonic(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 石勇虎 <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 21:31:10 |
| Message-ID: | 20180213213110.5ip4hsnu2hjz52ae@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2018-02-13 13:24:47 -0800, David Gould wrote:
> I see this problem fairly frequently. Typically the problem catalog is
> pg_attribute as it has the most rows. However the problem really arises when
> the catalogs become bloated. Once the total size of the catalogs that get
> read at start up approaches the size of shared buffers, and especially if
> several processes start at the same time, it becomes quite noticeable.
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.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next 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 |
| Previous Message | David Gould | 2018-02-13 21:24:47 | Re: response time is very long in PG9.5.5 using psql or jdbc |