On 11/06/10 23:38, David Jarvis wrote:
I added an explicit cast in the SQL:
dateserial(extract(YEAR FROM
m.taken)::int,'||p_month1||','||p_day1||') d1,
dateserial(extract(YEAR FROM
m.taken)::int,'||p_month2||','||p_day2||') d2
The function now takes three integer parameters; t
Szymon Kosok wrote:
I've found in mailing list archive that scale = 1 is not good idea. So
we have ran pgbench -s 200 (our database is ~3 GB) -c 10 -t 3000 and
get about ~600 TPS. Good or bad?
pgbench in its default only really tests commit rate, and often that's
not what is actually importan
On Sat, Jun 12, 2010 at 8:37 AM, Szymon Kosok wrote:
> 2010/6/12 Szymon Kosok :
>> PS. pgbench scale is set to "1".
>
> I've found in mailing list archive that scale = 1 is not good idea. So
> we have ran pgbench -s 200 (our database is ~3 GB) -c 10 -t 3000 and
> get about ~600 TPS. Good or bad?
2010/6/12 Szymon Kosok :
> PS. pgbench scale is set to "1".
I've found in mailing list archive that scale = 1 is not good idea. So
we have ran pgbench -s 200 (our database is ~3 GB) -c 10 -t 3000 and
get about ~600 TPS. Good or bad?
--
Greetings,
Szymon
--
Sent via pgsql-performance mailing li
Hello,
We are trying to optimize our box for Postgresql. We have i7, 8GB of
ram, 2xSATA RAID1 (software) running on XFS filesystem. We are running
Postgresql and memcached on that box. Without any optimizations (just
edited PG config) we got 50 TPS with pg_bench default run (1 client /
10 transact
