From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <books(at)ejurka(dot)com>, <simon(at)2ndquadrant(dot)com>, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Simplifying wal_sync_method |
Date: | 2005-08-09 00:06:22 |
Message-ID: | 4092.24.211.165.134.1123545982.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane said:
> Kris Jurka <books(at)ejurka(dot)com> writes:
>> Automated performance testing seems like a bad idea for the buildfarm.
>> Consider in my particular case I've got three members that all
>> happen to be running in virtual machines on the same host. What
>> virtualization does for performance and what happens when all three
>> members are running at the same time renders any results beyond
>> useless.
>
> Certainly a good point --- but as I noted to Andrew, we'd probably be
> more interested in one-off tests than repetitive testing anyway. So
> possibly this could be handled with a different protocol, and buildfarm
> machine owners could be careful to schedule slots for such tests at
> times when their machine is otherwise idle.
>
> Anyway it all needs some thought ...
>
Well, of course running tests would be optional.
But it's also possible that we would create a similar but separate setup to
run performance tests. Creating it would be lots easier this time around ;-)
Let's come up with something we can run by hand, decide the parameters, and
set set about automating and distributing it.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2005-08-09 00:15:49 | Re: Simplifying wal_sync_method |
Previous Message | Tom Lane | 2005-08-09 00:06:13 | Re: PL/pgSQL: SELECT INTO EXACT |