| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A test for replay of regression tests |
| Date: | 2022-01-27 22:21:58 |
| Message-ID: | CA+hUKG+U8kzBCgj61L9Q99vEN3rE+9Ok22L92izNyYrzHoGT1g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 28, 2022 at 11:03 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> That means every single psql started by 027_stream_regress.pl's pg_regress
> takes 2s. Which of course adds up...
That is very surprising, thanks. Will fix.
I've been experimenting with reusing psql sessions and backends for
queries in TAP tests, since some Windows animals seem to take a
significant fraction of a second *per query* due to forking and
startup costs. ~100ms or whatever is nothing compared to that ~2000ms
silliness, but it still adds up over thousands of queries. I'll post
an experimental patch soon, but this discussion has given me the idea
that pg_regress might ideally be able to reuse processes too, at least
sometimes...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-01-27 22:35:57 | Re: Design of pg_stat_subscription_workers vs pgstats |
| Previous Message | Andrew Dunstan | 2022-01-27 22:16:17 | Re: A test for replay of regression tests |