From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: reducing isolation tests runtime |
Date: | 2018-01-25 20:34:15 |
Message-ID: | 20180125203415.zdoyjqpx5nzwcryk@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > I think we could solve this by putting in the same parallel group only
> > slow tests that mostly sleeps, ie. nothing that would monopolize CPU for
> > long enough to cause a problem. Concretely:
> > test: timeouts tuplelock-update deadlock-hard deadlock-soft-2
>
> OK, but there'd better be a comment there explaining the concern
> very precisely, or somebody will break it.
Here's a concrete proposal. Runtime is 45.7 seconds on my laptop. It
can be further reduced, but not by more than a second or two unless you
get in the business of modifying other tests. (I only modified
deadlock-soft-2 because it saves 5 seconds).
Admittedly the new isolation_schedule file is a bit ugly.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Parallelize-isolation-tests-a-bit.patch | text/plain | 7.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-25 20:58:04 | Re: reducing isolation tests runtime |
Previous Message | Tom Lane | 2018-01-25 20:27:29 | pgsql: Support --no-comments in pg_dump, pg_dumpall, pg_restore. |
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2018-01-25 20:38:13 | Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem |
Previous Message | Tom Lane | 2018-01-25 20:33:50 | Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump |