| 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:37:09 |
| Message-ID: | 9029.1518561429@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:
> One of the OP's examples shows the connection establishment separate
> from the slowdown however. Shouldn't that preclude relcache init file
> rebuilds being involved?
Hmm ... I was thinking that psql might be able to produce a prompt before
the connected backend was done initializing, but after a bit more poking
into the code that seems unlikely. Still, it might be interesting to
verify whether the first command is fast if it's one that requires no
catalog access. Maybe "set enable_hashjoin = 1" or suchlike (being
careful not to invoke tab completion to type it ;-)).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Gould | 2018-02-13 22:42:24 | Re: response time is very long in PG9.5.5 using psql or jdbc |
| Previous Message | Andres Freund | 2018-02-13 22:21:02 | Re: response time is very long in PG9.5.5 using psql or jdbc |