Tomas Vondra writes:
> Should we change the type of nxacts to int64 (thus allowing '-t' with
> 64-bit integers), or just the overflow in the printf call? I don't find
> it very practical to use -t with values not fitting into 32-bits (the -T
> seems better to do that), so I'm inclined to just fix
On 25.5.2014 20:32, Tom Lane wrote:
> Tomas Vondra writes:
>> On 25.5.2014 19:05, Andres Freund wrote:
>>> That's not right though. On windows a long (indicated by the %l) is only
>>> 4 bytes wide. Check INT64_FORMAT. That's generated by configure/platform
>>> template files and should always be c
Tomas Vondra writes:
> On 25.5.2014 19:05, Andres Freund wrote:
>> That's not right though. On windows a long (indicated by the %l) is only
>> 4 bytes wide. Check INT64_FORMAT. That's generated by configure/platform
>> template files and should always be correct.
> Oh, right. v2 of the patch atta
On 25.5.2014 19:05, Andres Freund wrote:
>> printf("number of transactions per client: %d\n", nxacts);
>> -printf("number of transactions actually processed: %d/%d\n",
>> +printf("number of transactions actually processed: %ld/%d\n",
>> n
Hi,
On 2014-05-25 18:05:03 +0200, Tomas Vondra wrote:
> I've been running a few longer pgbench tests (~week), and I've run into
> this:
> number of transactions actually processed: -1785047856
> latency average: -10.846 ms
> tps = -2950.492090 (including connections establishing)
> tps = -2950.49
Hi,
I've been running a few longer pgbench tests (~week), and I've run into
this:
transaction type: SELECT only
scaling factor: 1250
query mode: simple
number of clients: 32
number of threads: 4
duration: 605000 s
number of transactions actually processed: -1785047856
latency average: -10.846 ms
