Justin Pryzby writes:
> I can reproduce the issue with generated data:
> pryzbyj=# SELECT format('create table t%s(i int)', i) FROM
> generate_series(1,)i;
Hm, I tried this case and didn't really detect much runtime difference
between v12 and HEAD.
> I don't know if it's any issue, but I
On Thu, Aug 13, 2020 at 08:53:46PM -0400, Alvaro Herrera wrote:
> Hmm, I wonder if you're comparing an assert-enabled pg13 build to a
> non-assert-enabled pg12 build, or something like that.
Great question - I thought of it myself but then forgot to look..
$ rpm -q postgresql1{2,3}-server
Hmm, I wonder if you're comparing an assert-enabled pg13 build to a
non-assert-enabled pg12 build, or something like that.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I can reproduce the issue with generated data:
pryzbyj=# SELECT format('create table t%s(i int)', i) FROM
generate_series(1,)i;
\set ECHO errors
\set QUIET
\gexec
$ time pg_dump --section=pre-data -d pryzbyj -h /tmp -p 5613 |wc
110015 240049 1577087
real0m50.445s
$ time pg_dump
Hi,
On 2020-08-13 17:48:23 -0500, Justin Pryzby wrote:
> I'm trying to narrow this down, but I'd be very happy for suggestions.
Would be worth knowing how much of the time pgbench is 100% CPU
utilized, and how much of the time it is basically waiting for server
side queries and largely idle.
If
On 2020-Aug-13, Justin Pryzby wrote:
> I'm trying to narrow this down, but I'd be very happy for suggestions.
Maybe you can time "pg_dump --binary-upgrade" to see if the slowness
comes from there.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
I ran into this while running pg_upgrade from beta2 to beta3:
$ time sudo -u postgres sh -c 'cd /var/lib/pgsql; /usr/pgsql-13/bin/pg_upgrade
-b /usr/pgsql-13b2/bin/ -d ./13b2/data -D ./13/data --link'
real94m18.335s
This instances has many table partitions, and the production
