ITAGAKI Takahiro wrote:
> The only thing I worried about is portability issue. POSIX functions
> like alarm() or setitimer() are not available at least on Windows.
> I expect alarm() is available on all platforms except Win32 and
> used CreateTimerQueue() instead on Win32 in the new patch.
> (We h
Tom Lane <[EMAIL PROTECTED]> wrote:
> My understanding is that it's basically "cheap PC hardware" (with clock
> interfaces based on old ISA bus specs) that has the issue in a
> significant way. I wouldn't expect you to see it on a serious database
> server. But lots of people still do developme
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Greg Smith wrote:
>> Last time I tried to quantify the overhead of logging with timestamps on
>> I couldn't even measure its impact, it was lower than the usual pgbench
>> noise.
> There's a hardware deficiency on certain machines -- I think it's old
Greg Smith wrote:
> On Mon, 18 Aug 2008, Tom Lane wrote:
>> I repeat my concern that transaction rates measured with this patch will
>> be significantly different from those seen with the old code
>
> Last time I tried to quantify the overhead of logging with timestamps on
> I couldn't even measu
On Mon, 18 Aug 2008, Tom Lane wrote:
the seldom-used log-each-transaction option, which pretty obviously
is a drag on performance anyway
I always recommend that people run with log each transaction turned on,
beause it's the only way to gather useful latency information. I think
runs that
Greg Smith <[EMAIL PROTECTED]> writes:
> On Tue, 12 Aug 2008, Tom Lane wrote:
>> This seems like a fairly bad idea, because it introduces a
>> gettimeofday() call per transaction.
> There's already lots of paths through pgbench that introduce gettimeofday
> calls all over the place. I fail to se
On Tue, 12 Aug 2008, Tom Lane wrote:
This seems like a fairly bad idea, because it introduces a
gettimeofday() call per transaction.
There's already lots of paths through pgbench that introduce gettimeofday
calls all over the place. I fail to see how this is any different.
If this were wo
Tom Lane <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > Here is a patch to add duration option (-T) to pgbench instead of
> > number of transactions (-t). -t and -T are mutually exclusive.
>
> This seems like a fairly bad idea, because it introduces a
> gettimeofda
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Here is a patch to add duration option (-T) to pgbench instead of
> number of transactions (-t). -t and -T are mutually exclusive.
This seems like a fairly bad idea, because it introduces a
gettimeofday() call per transaction. On lots of (admittedly
Hello,
Here is a patch to add duration option (-T) to pgbench instead of
number of transactions (-t). -t and -T are mutually exclusive.
$ pgbench -n -S -c10 -T10
transaction type: SELECT only
scaling factor: 1
query mode: simple
number of clients: 10
number of transactions actually processed: 225
10 matches
Mail list logo
